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.
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.
In theory, theory and practice are the same. In practice they differ. :-)
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)
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:
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).
Regards,
Antonis
Antonis Christofides
http://djangodeployment.com
On 10/21/2017 10:29 AM, James Schneider wrote:
>
>
> What I do is I create a superclass that I call Lentity (short for "legal
> entity", despite the fact that it could refer to a group of people and is
> not
> necessary legal) and the two subclasses Person and Organization, with
> multi-table inheritance.
>
>
> Seems silly to name a model as such given that it can easily be
> nonrepresentative of the data in the table.
>
> Is it an abstract class? If yes, why not just call it Entity? A legal status
> can easily be represented by a field in the model.
>
> If a Person and Organization are treated the same, you can also use just an
> Entity table with a field designating the type of Entity, such as 'person' or
> 'organization'. Querying all Person and Organization objects would then
> constitute only a single query, rather than two queries, one for each model
> type. If you add other similar models, you also increase the number of queries
> required to pull all of the objects, whereas a field designation allows you to
> pull some or all objects regardless of type.
>
> There are a ton of reasons to keep them separate, though, so your design may
> still be correct.
>
> -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
> <mailto:django-users+unsubscr...@googlegroups.com>.
> To post to this group, send email to django-users@googlegroups.com
> <mailto: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%2BciX21jrrdceNoq4VpthKoc%2BH-g2LbOs%3D4xkV5HKxo0cVJA%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-users/CA%2Be%2BciX21jrrdceNoq4VpthKoc%2BH-g2LbOs%3D4xkV5HKxo0cVJA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.
--
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/4cabb1b7-f8fc-6b1e-6d54-5ad4ea00b36e%40djangodeployment.com.
For more options, visit https://groups.google.com/d/optout.
