#24317: Deprecate field.rel, replace it with real field instances
-------------------------------------+-------------------------------------
Reporter: akaariai | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | 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 akaariai):
My current thoughts of how relation fields should work is:
A relation in Django consits of:
- The field itself
- A descriptor to access the objects of the relation
- The descriptor might need a custom manager
- Possibly a remote field (the field to travel the relation in other
direction)
- The remote field can contain a descriptor and a manager
- For deprecation period, field.rel is something like the remote field,
but without
actually being a field instance.
The loading order is as follows:
- The relation field is created as part of loading the class (or
completely separately
by migrations for example).
- The relation field is added to the class (contribute_to_class is
called). The field is
added to model's _meta.
- When both the origin and the target classes are present, the
remote_field is created
and the descriptors are added. The remote field is added to the target
class' _meta (note:
the target class' _meta wasn't touched before the remote fields
refactor!)
- For migrations it is possible that a model is replaced live in the
app-cache. For example,
assume model Author is changed, and it is thus reloaded. Model Book
has foreign key to
Author, so its reverse field must be recreated in the Author model,
too. The way this is
done is that we collect all fields that have been auto-created as
relationships into the
Author model, and recreate the related field once Author has been
reloaded.
I also thought of making field.rel actually a field subclass. But I'm not
too enthusiastic of doing this, this ties the new implementations to the
old Rel API. It seems better to write the new remote fields from scratch,
and then make them as much as possible Rel like for deprecation period
(the problem being that field.rel instances are what you get from
_meta.get_field[s]() calls).
Note that even if this ticket is accepted, this work is still in early
stages, and it isn't that clear how we actually want to do this. Maybe a
DEP is in order for this? However, it is clear to me that we want to do
*some* cleanup. It isn't nice at all that you can get instances that
implement different APIs from get_field() and friends.
--
Ticket URL: <https://code.djangoproject.com/ticket/24317#comment:2>
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 django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.fb68234d67c14e6cfd086c187041860d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
