On Wed, Mar 31, 2010 at 4:35 PM, Flo <d3f3n...@bytegeist.org> wrote: > > Here an updated, fresh summary: > > > > Plan > ------- > > Add an abstraction layer to the auth.User class > > > > Method > --------- > > An extra abstraction layer will be added for the User class in form of > a BaseUser class. The BaseUser class will consist of : > > * the whole permission stuff (user_permissions, > get_group_permissions, get_all_permissions,....), > * the the authentication stuff (is_anonymous and is_authenticated, > last_login, date_joined, groups) > * the fields for admin (is_staff, is_superuser) > * a single ident field > > > The interface will look something like this: > > class BaseUserPermission: -> abstract > - user_permissions > - groups > - get_group_permissions() > - get_all_permissions() > - has_perm() > - has_module_perms() > - ….. > > class BaseUserAuthentication: -> abstract > - last_login > - date_joined > - is_anonymous() > - is_authenticated() > - ….. > > class BaseUserAdmin: -> abstract > - is_staff > - is_superuser > > class BaseUser(BaseUserAuthentication, BaseUserPermissions, > models.Model): > - ident > - …..
I'm not entirely clear what we gain by having multiple base classes. If every application that wants to reference User needs to have a foreign key on BaseUser, then the base classes of BaseUser are irrelevant. It's not like I could define my own User class that used a different UserAuthentication or UserPermissions class. > All specific user classes (for example a class for login via a Twitter > user) will have to extend BaseUser via Multi-Table inheritance. The > new Django auth.User will have the same fields and methods as the old > User, but it will inherit the fields and mehtods for permissions, > authentication and admin. > To add your custom user class for remote login via Twitter/ > Facebook..... you will only have to extend base user and add the > fields you need (no more linking to the old auth.User and having a lot > of fields you don't need, username and password (because the login is > handled via an external service) for example). The new existing Django > user class can be modified via inheritance too (for example adding > another permission model or additional authentication information). > > While the new User class won't break code compatibility, because it > will contain all the fields and methods the "old" User class does, it > will break database compatibility, because the new User will consist > of two or more database tables. Two ways of dealing with the new user > class will be supported: Erm.. aren't these two approach mutually exclusive? i.e., if we force a migration, we won't need NewUser at all. > Use the new system: > A tool for migrating the database will be provided to support the > transition from old to new. The script will work to following way: I have to say I'm *really* not a fan of this. Completely aside from the complexities associated with dumping and recreating your entire collection of user data, this is a nightmare waiting to happen from a project management point of view. We aim to make Django point releases "just upgrade and you'll be able to keep running". The defaults of any new features are specifically designed to avoid update problems. Putting a forced data migration as part of the upgrade path sounds like a recipe for putting me in an early grave. > Don't use it: > The new User class will be introduced as auth.NewUser and the old > User class won't be touched, so all apps, that rely on the old User > will work as well. Of course, the Django internals have to modified to > work with both User systems, the "old" and the "new" one. That last sentence is a fairly big thing to gloss over. How exactly will this magical parallel support be implemented? What changes are required in core to utilize this parallel support? Are they the same changes that external applications will need to make? > In the long term NewUser will replace the current auth.User. The > deprecation plan will look like: > > * 1.3 > The new system can be activated via USE_ABSTRACT_USER=True in > settings (default False). Inside your app, the new User class will be > imported as : "from django.contrib.auth.models import NewUser as User" > The use of the old User will raise a PendingDeprecationWarning > > * 1.4 > raise a DeprecationWarning, if the old auth.User is used > > * 2.0 > NewUser will become User, support for old User will be dropped Again - a kind of big detail to gloss over... the release after 1.4 won't necessarily (in fact, almost certainly won't be) be 2.0. How long do you expect us to maintain parallel support? > Benefits > ------------ > > * Apps can link pages, posts,..... to BaseUser and become > independent from the underlying user class -> underlying user classes > are exchangeable -> apps are more portable > * User classes for remote authentication without unused fields (like > password, username...) > * clear, object oriented User classes This last point might sound great to a Java developer, but arguing OO=better won't necessarily win you the hearts and minds of Python developers. Don't get me wrong - OO is useful and has its place. However, it isn't always a guaranteed win. For example, there is a very significant cost to your OO proposal that you have consistently overlooked - the fact that using OO requires an additional table join. This join doesn't come for free, and I'm not yet convinced that it actually improves flexibility to force the extra join on everyone. 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 django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
