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 [email protected]
> <mailto:[email protected]>.
> To post to this group, send email to [email protected]
> <mailto:[email protected]>.
> 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 [email protected].
To post to this group, send email to [email protected].
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.
