So, the last major bug left in migrations that I'm aware of (bar the
completion of the GIS backends) is dealing with swappable models - in
particular, of course, AUTH_USER_MODEL.

As long as you're not using any third-party apps, then everything works
fine, but as soon as third-party apps with migrations come into the picture
there's an issue. These apps have to ship with migrations that reference
any project's current user model - and the way swapping is currently done
means that ForeignKeys end up with concrete references to the user model
_at the time the migration was made_.

There are a couple of potential approaches here:

1) Introduce a new value that can be used as a "to" parameter on
ForeignKeys which resolves to a swapped model in its internal
string-to-model converter. I'm thinking something like
"__swapped__.AUTH_USER_MODEL" - I would use settings here, but I can
imagine people having an app called settings.

The problem here is I'd then have to make ForeignKey deconstruct to this
special value if the model it was pointing to was the replacement model -
whether or not it's got settings.AUTH_USER_MODEL in the models.py file
(there's no way to tell if it has an actual string or a setting reference
in its models.py declaration). This means that some FKs might be too
eagerly converted into swapped references.

1b) Like 1), but rather than having the value automatically inserted,
require apps to actually use this new string rather than a direct reference
to settings.AUTH_USER_MODEL, meaning we can tell if it's swapped or not and
deconstruct it appropriately.

2) Change ForeignKey's constructor to automatically point itself to the new
swapped-in model if it's pointing to the model that was swapped out (so
ForeignKey("auth.User") automatically becomes
ForeignKey("myapp.CustomUser") internally.


Now, I prefer the cleanliness of 2), but I suspect there was a reason this
wasn't done when swappable models were first introduced; that said, I
haven't seen any coding patterns in the wild this would disrupt.

Opinions?

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFwN1uow9u0w_GOS8qRhBmNz%3D6r0vMHXx4guFf967wZeUnDVuQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to