#19385: Add support for multiple-column join
-------------------------------------+-------------------------------------
Reporter: cseibert | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: 1.4
(models, ORM) | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: join | Needs documentation: 0
Has patch: 1 | Patch needs improvement: 1
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Comment (by akaariai):
Reading through the patch I found a couple of things in need of fixing or
at least closer inspection before this can be committed:
- column_fields, local_column_fields -> concrete_fields,
local_concrete_fields, do these need better caching for `__init__` speed?
- requires_unique_target validation must check unique_together indexes,
too
- Model.`__init__`, "# This field will be populated on request" if
condition cleanup
- possible problems from related field lookup value resolving (the
_pk_trace() change). The new code seems to be doing better job than the
old code (validating that the related model is of right class, not blindly
using PK instead of the relation's real target field). If regressions
happen here they should be somewhat straightforward to fix.
- native_related_fields -> better name?
I was thinking of renaming all [*_]related_fields to [*_]relation_fields.
Also, rename native_related_fields to local_relation_fields,
foreign_related_fields to remote_relation_fields. Similar for the
get_..._value() methods.
Otherwise I think this patch is ready. split_exclude() at least doesn't
yet work correctly for multicol joins, but that can be fixed later on.
There are likely other places needing some work, too. All in all there is
somewhat big risk of regressions but IMO the risk is worth it.
If anybody wants to do a review of this now is the time. Doing a quick API
level check would be good. Commit is going to happen real soon now.
Abstract of the patch for those not wanting to read through the whole
patch: the patch adds models.fields.related.ForeignObject which is a
virtual field marking a connection from_fields -> to_fields. In addition
the patch adds support for traversing these multicolumn connections into
ORM. When plain ForeignObject is used it is added to ._meta.fields. Those
fields which have a concrete database column will be present in
._meta.concrete_fields, too (still named column_fields in the patch).
ForeignKey and GenericRelation are special cases of ForeignObject,
ForeignKey has just single from_fields and to_fields entries, and also has
a concrete column. GenericRelation is still using ._meta.virtual_fields
only. After the patch it will be possible to make the ORM handle
multicolumn relations even if multicolumn ForeignKey isn't available using
public APIs. Examples of what can be done is in
tests/foreign_objects/models.py and tests.py.
--
Ticket URL: <https://code.djangoproject.com/ticket/19385#comment:30>
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].
For more options, visit https://groups.google.com/groups/opt_out.
