#29899: Adapt the auto-detector to detect changes from model states instead of
model classes
-------------------------------------+-------------------------------------
Reporter: Simon Charette | Owner: David
Type: | Wobrock
Cleanup/optimization | Status: assigned
Component: Migrations | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by David Wobrock):
* cc: David Wobrock (added)
* owner: nobody => David Wobrock
* status: new => assigned
Comment:
Hi there,
I got more or less my head around what is asked in the ticket and how it
would improve the autodetector. However, I have some questions and I'd
like to ask for some help and expertise on this issue.
I'll just shoot my questions:
1. Am I understanding correctly that, by using the ModelState objects,
instead of the rendered model objects/classes, we avoid calling the
ProjectState.apps and ProjectState.concrete_apps (in the
Autodetector.__init__) which are rendering the models? Therefore, we avoid
work and speed up the makemigrations and migrate commands?
But since the "from_state" is still generated from the migration graph, we
will still apply all existing migrations iteratively to build it, right?
So we cannot totally avoid exploring the migration graph?
And let's get down to some more technical business :) I started re-working
the patch, it's still a work in progress, but I think most of the logic of
the autodetector is migrated to using model states. You should be able to
look at the patch commit-by-commit for convenience. I'll still need to
work on tests, fix the existing ones and adding some new ones to ensure I
introduced no regression. Please find my current progress here
https://github.com/django/django/compare/master...David-
Wobrock:ticket-29899?expand=1
2. The one thing about the logic which I'm unsure of, is the "relations"
property which is introduced in the ProjectState. The goal is, I guess, to
substitute the "related_objects" that a model class' option contains.
However, I don't fully understand how the "proxies", "concrete" models and
"swappable" ones work together.
I see that we are trying to fill the relations, for each model (identified
by app_label+model_name), have the related models (identified by the same
key) and the associated fields that have a relation. It's not easy to get
your head around the 4 consecutive loops.
- What are those relations exactly? All possible defined FK (also m2m,
...) on the model itself? Or also fields FK that point to this model?
- And would it possible, even quickly, to explain how "swappable", "proxy"
and "concrete" work together, I'd be grateful. I mean, I guess that we
need to resolve the real/concrete model from a proxy model, but
"swappable" is my main source of confusion here and I don't know how it
should be handled :/ Like a proxy model because we resolve the concrete
model when the User model is swappable?
Thanks a lot in advance! I'm assigning myself the issue.
--
Ticket URL: <https://code.djangoproject.com/ticket/29899#comment:1>
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/067.9d4a47470a12079b14295c21a6c0e77a%40djangoproject.com.
