I would also consider a "last known good display name" field on the MinimalUser table, so things like contrib.comments have something to display as well as something to FK to.
I am interested in figuring this one out too. If you do fork django on github, send me a pointer. I think it would take clean working versions of everything (contrib.comments, admin, etc.) for this to go anywhere soon. Zellyn On Oct 21, 5:02 am, Russell Keith-Magee <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
