On Wednesday 08 January 2014 18:04:44 Andrew Godwin wrote:
>
> 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?
>
Instinctively, I'm almost -1 on 2); I'm not too happy about 1) either. If a
model says it has a FK to auth.User, that shouldn't mean anything other than
auth.User. I don't see that as cleanliness -- it's effectively monkeypatching.
1b seems to me like the most reasonable option.
However, I've had a different thought about this:
> As long as you're not using any third-party apps, then everything works
> fine
No, it doesn't really. You can't change the user model as part of the project
evolution. Supporting this raises a whole set of additional problems -- even
with 1b, not to mention the scenarios where we try to guess swappables from
concrete models that happen to be their sources or targets.
This is a problem that bugs me personally -- I'm involved in a big project
that evolved since Django 1.2. As 1.4 (no swappable user model) is LTS, I'm
certain it's not just me.
Shai.
--
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 [email protected].
To post to this group, send email to [email protected].
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/201401081950.11502.shai%40platonix.com.
For more options, visit https://groups.google.com/groups/opt_out.
