Yes, Child would be "unrelated" in the sense that it doesn't have any
connections to its parent
other than the fields. Is the problem that this uses the inheritance
semantics?
Python doesn't offer a mechanism for accessing parent objects or vice
versa, this is something you
will have to implement yourself if you want it. So I don't see how this
would be surprising for
any python programmers.
The relational inheritance can actually cause data corruption when you
don't expect the parents
data to be a superset of the childrens data. However, the the parent's
definition may still be
a superset of the childrens definition, if you don't override any fields.
As an example of this, consider:
class 3DTable(models.Model):
width = models.IntegerField()
height = models.IntegerField()
depth = models.IntegerField()
class 4DTable(3DTable):
some_other_dimension = models.IntegerField()
Now, of course this depend of what a 4DTable is. It may NOT even be
projectible in the 3D space at all, at least not in a sensible way. So it s
houldn't be presented as if it were.
As for the definition, they are mostly the same, 4DTable adds another
dimension. It should in this case inherit the definition only.
Den torsdag 3 mars 2016 kl. 12:36:08 UTC+1 skrev Aymeric Augustin:
>
> Hi Joakim,
>
> On 03 Mar 2016, at 11:03, Joakim Saario <[email protected] <javascript:>>
> wrote:
>
> > The problem is that django hijacks the class-inheritance feature of
> python and uses it soley
> > for relational inheritance.
>
>
> I understand that you would like each model class to have its own table
> with all its fields,
> whether they’re defined in this class or in a superclass.
>
> However, according to the regular OOP model, Django considers that
> children ORM classes
> specialize their parent class. You must be able to take a child instance
> and cast it to a parent
> instance by throwing away attributes not used in the parent and using the
> parent’s methods.
>
> In other words, if Child.objects.get(pk=1) works, Parent.objects.get(pk=1)
> is supposed to give
> you a Parent instance that is a more generic version of the Child
> instance. (I have to admit
> that this isn’t always true with Django. If the Parent is abstract,
> Parent.objects.get will raise
> an exception.)
>
> My main concern with your proposal is that Parent.objects.get(pk=1) would
> return an object
> that is totally unrelated to Child.objects.get(pk=1)! I have a hard time
> believing this qualifies
> as “regular class inheritance”. I suspect many Python programmes would
> find it surprising.
>
> That is why Django cannot ignore the fact that an ORM model is backend by
> a database
> table. It needs to decide what table to use — or disable database access
> entirely to avoid
> this problem.
>
> I’m sorry if this feels like “hijacking” to you. It’s prevents data
> corruption bugs, though.
>
> Best regards,
>
> --
> Aymeric.
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" 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-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/e29047cf-fc18-47e5-8003-5576dca7252d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
