On Oct 21, 2017 2:06 AM, "Antonis Christofides" <
anto...@djangodeployment.com> wrote:
Hello James,
You are right that the correct term in everyday language for the superclass
of organization and person is "entity". However, I didn't want to name it
"entity" in the code, because, really, "entity" is a different thing in
programming, it's a term like "object". It would be very confusing. The
reason I didn't name it LegalEntity is exactly that it might not be legal.
I chose to invent a new term, "Lentity", which ensures that someone will
not (mis)understand it just by looking at the name and will necessarily
look it up.
IMO if you name things in such a complicated fashion that others have to
look them up, they probably aren't very good names. Even worse that you've
arbitrarily shortened the name non-intuitively. I don't like it, but if it
works for you, more power to you.
I think that my design is "correct" from a theoretical point of view.
Inheritance is the way to solve such a problem in OOP, and multi-table
inheritance is the way to solve this problem in relational databases.
That's what the books say anyway.
Usually, but in this case, your OOP design also influences your DB schema,
which has different implications and philosophy to consider. RDB's don't
support the concept of inheritance AFAIK.
In theory, theory and practice are the same. In practice they differ. :-)
Always.
My design generally works and I'm quite satisfied with it. This doesn't
mean it's without problems. So, for example, the original definition of
Lentity in an app of mine was this:
class Lentity(models.Model):
def __str__(self):
try:
return str(self.person)
except Person.DoesNotExist:
return str(self.organization)
This code makes no sense. You should not be referring to models directly.
Everything should be relative to self. It should be as simple as return
self.name, with a property called name on each child model that returns the
correct field.
Or don't bother overriding it at all at this level and override it properly
in each child model.
class Meta:
verbose_name_plural = 'Lentities'
Then, when I had too many persons and organizations, I had to use
raw_id_fields in the admin, and for this I had to make this change:
Not sure why having a larger list prompted the use of raw ID fields.
Usually it's the opposite.
class Lentity(models.Model):
# descr is a redundant field; see save() for more information.
descr = models.CharField(max_length=111, blank=True, editable=False)
def __str__(self):
try:
return str(self.person)
except Person.DoesNotExist:
return str(self.organization)
def save(self, *args, **kwargs):
# descr is a redundant, calculated field that is automatically filled
# in during save(). We introduce this redundancy because there is
# currently no other way in which the Django admin can sort lentities,
# i.e. we can use descr as a field in "ordering" or "get_ordering", but
# it's not possible to use an expression. (We need the Django admin to
# manage lentities in general, as well as persons and organizations, in
# order to make it possible to use raw_id_fields in AuthorInline.)
self.descr = str(self)
super(Lentity, self).save(*args, **kwargs)
class Meta:
verbose_name_plural = 'Lentities'
So I had to put Lentity in the admin, ensuring users have no permissions to
edit or delete or create "Lentity" directly, and I told users to just
ignore that. (I'm can't tell whether these problems are worse than having
two fields plus a discriminator field in the admin).
There are some weird design issues here that I don't have time or context
to comment on. Seeing the words 'redundant' and 'field' in the same
sentence worries me as far as database schema design goes. But if it is
working for you...
-James
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/CA%2Be%2BciWD8oqUss5GHN1%3DzoLoZqVLC47vJxHxuGL%2BADDngZmWtg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
