#24289: Is usage of many_to_one and one_to_many terms confusing for relation
flags?
-------------------------------------+-------------------------------------
Reporter: akaariai | Owner: nobody
Type: Bug | Status: new
Component: Database layer | Version: 1.8alpha1
(models, ORM) |
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by carljm):
Hi Anssi,
Replying to [comment:13 akaariai]:
> I don't think reversing the many_to_one and one_to_many definitions will
help. The terms are confusing, no matter which way they are used,
I think either way we use them, most people will simply adapt their code
to Django's and it will be fine. But I still think we should use them as
correctly and consistently as we can, and in the way that is least likely
to result in confusion.
> and I believe the terms are used the correct way (as in, the most often
seen definition)
I am curious if you have evidence to support this, because I have
concluded the opposite, based on my searches, as documented in comment 5.
The strongest evidence I have is that Hibernate uses a `@ManyToOne`
annotation to annotate the equivalent of a Django ForeignKey, and a
`@OneToMany` annotation to annotate the reverse relationship. Hibernate is
a very well-known and widely-used Java ORM -- do you think that their
usage is wrong/uncommon?
> I see two ways forward:
> - Keep the flags as is. Maybe add a bit more documentation somewhere
that tell explicitly what these flags mean in Django.
I have not seen any good argument yet to stay with the status quo, instead
of flipping them to match the usage in e.g. Hibernate.
> - Use some other flags for relations. A possibility is local_multiple
and remote_multiple flags. These flags would tell if a single object can
have multiple objects. remote_multiple tells that the local object can
have multiple objects on the remote side. local_multiple is the opposite:
can a single remote object have multiple objects on the local side. Still
a bit confusing, but I think these are easier to recall correctly.
Possibly. My only problem with this is that since we have
`ManyToManyField` and `OneToOneField` (and those names are certainly not
changing), it makes a lot of sense to keep the `many_to_many` and
`one_to_one` flags. And once we have those two, it seems like a natural
extension to also have `many_to_one` and `one_to_many`, rather than
introducing an entirely new terminology.
> A bonus of the second approach is that I believe the local_multiple and
remote_multiple properties are what we are most often interested about: we
can select_related if the relation is remote_multiple=False. We need to
use subqueries with .exclude() when the relation is remote_multiple=True.
The widget in forms is SelectMultiple when remote_multiple=True.
This is a good point.
> We could also use just a has_many flag, but then it's hard to say if an
ArrayField should have has_many set. The remote_multiple is better, as it
is explicitly about relations.
>
> We could even have both n_to_n flags, and the local_multiple and
remote_multiple flags. We could use the checks framework to warn if the
flags aren't defined in a consistent way.
I like this idea in theory, though I would like to see a patch for this to
verify that `local_multiple` and `remote_multiple` are in fact as useful
internally as it seems they should be.
I think if we introduce `local_multiple` and `remote_multiple` with the
semantics you suggest, it makes it even more important that we swap the
current usage of `many_to_one` and `one_to_many`. It just seems entirely
wrong to have a field labeled `one_to_many` with `local_multiple=True` and
`remote_multiple=False`, which is what the status quo would mean.
--
Ticket URL: <https://code.djangoproject.com/ticket/24289#comment:16>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" 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].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.258a283fe667495c3c166716ff052033%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
