Good points. Regarding 1), I can't specially control reconstruction of
fields from migrations and raise errors only in that case - it's just
calling the normal __init__. Since I'm going to have to write out a call to
settings.AUTH_USER_MODEL anyway - the whole point of swappable=True is so
the migr
On Thursday 09 January 2014 01:10:09 Raphaël Barrois wrote:
> On Wed, 8 Jan 2014 20:27:54 +0200
>
> Shai Berger wrote:
> > as people already use auth.get_user_model() -- so, you can
> > monkeypatch *that* when generating migrations, and let them just keep
> > doing what they do today.
>
> Actual
On Saturday 11 January 2014 11:45:55 Andrew Godwin wrote:
> OK, I like that approach Russ - an inverted 1b. It'll be a bit harder to
> explain in the docs, but it won't catch anyone out unawares, which is the
> key thing.
>
I like it too.
And foot-in-mouth re referencing swappables notwithstandin
OK, I like that approach Russ - an inverted 1b. It'll be a bit harder to
explain in the docs, but it won't catch anyone out unawares, which is the
key thing.
Andrew
On Thu, Jan 9, 2014 at 1:28 AM, Russell Keith-Magee wrote:
>
>
>
> On Thu, Jan 9, 2014 at 12:04 AM, Andrew Godwin wrote:
>
>> So,
On Thu, Jan 9, 2014 at 12:04 AM, Andrew Godwin wrote:
> 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
> I don't see how "you need to remember that auth.User really means some
> model
> defined in settings" is more user friendly than "you need to remember that
> __swappable__.X means that X is swappable". More so, as people already use
> auth.get_user_model() -- so, you can monkeypatch *that* when g
On Wed, 8 Jan 2014 20:27:54 +0200
Shai Berger wrote:
> On Wednesday 08 January 2014 20:00:25 Andrew Godwin wrote:
> > > 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.U
On Wednesday 08 January 2014 20:00:25 Andrew Godwin wrote:
> > 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
> > monk
Personally, I like approach 2. It means that if we (or another 3rd party
app) were to make a model swappable, then migrations which don't know about
this change would continue to work.
On 8 January 2014 18:00, Andrew Godwin wrote:
>
>> Instinctively, I'm almost -1 on 2); I'm not too happy about
>
>
> 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.
>
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
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 migr
12 matches
Mail list logo