On Wed, Oct 21, 2009 at 2:55 PM, Hanne Moa <[email protected]> wrote: > > On Tue, Oct 20, 2009 at 16:18, Russell Keith-Magee > <[email protected]> wrote: >> >> On Mon, Oct 19, 2009 at 11:52 PM, Hanne Moa <[email protected]> wrote: >>> >>> It doesn't look like Contrib-06, covering ticket #3011, Allow for >>> extendable user module, will be in for 1.2. This is >>> my pony for *2.0*: >> >> I completely agree that we need to do something about #3011. /../ >> However, the time has really past for big ticket discussions for v1.2, >> and it certainly isn't the time to talk about ponies for v2.0. > > Saying it's for 2.0 makes it possible to ignore backwards compatibility...
Possible doesn't necessarily mean encouraged, and there still needs to be a clear migration path. On top of that, 2.0 isn't "just around the corner" - its several years away from even being a likely topic for discussion. Lastly, if we can find a deprecation path rather than a backwards incompatibility, we don't have to wait until 2.0 - we can do it in a series of v1.X releases. >> One of the big problems that needs to be solved that you haven't >> addressed is the migration path. Obviously, we can't just replace the >> current auth.User model - we need to have a migration plan for all >> existing users of contrib.auth. > > auth.User as an "auth-profile" on the MinimalUser, then it could start > out looking exactly as today except having its primary key be a > foreign key. Then we could make some of the other fields on auth.User > fetch its data from minimalUser. That is an interesting approach - I hadn't considered that. There might be some complications around models that have existing foreign keys on User - obviously, they will continue to work, but if a foreign key on MinimalUser is more appropriate, there is a different migration issue. > The tricky part IMO is getting 3rd parties to use the MinimalUser so I > foresee the big job as to rewrite tons of examples, tutorials, howtos. > Pushing it, basically. Oh and there should be screencasts, I love > those. ... And I want a pony :-) >> I have some ideas on how this could be done, but I'd be interested >> in hearing what others come up with. There are also complications >> with integrating with admin that need to be worked through. > > Sometimes it seems babying the admin is keeping us from doing a lot of > cool stuff. I couldn't use the admin at all in my very first django > project (legacy database + cranky DBA), so I guess I never grew used > to having it available. Like it or not, the admin has always been a big draw card feature of Django. I know that the admin isn't perfect for every situation, but I've also lot track of the amount of time it has saved me over the years. I can guarantee you that any proposal that starts with "lets ignore the admin" isn't going to get much traction with the core team. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
