I believe changes to auth (and several other things) are waiting for contrib.migrations. It will be some time...
On Sunday, 19 August 2012 03:02:51 UTC+1, Victor Hooi wrote: > > Hi, > > I'm just wondering, has there been any updates on the User model refactor? > > My understanding is that this is the official way of handling Users going > forward. > > Is there any roadmap on when it might hit trunk? I didn't see any > reference to User models in the 1.5 release notes. > Cheers, > Victor > > On Wednesday, 6 June 2012 21:34:42 UTC+10, Andrew Ingram wrote: >> >> On 4 June 2012 16:12, Russell Keith-Magee <[email protected]> >> wrote: >> > * The swapping mechanic is set up using a new Meta option on models >> > called 'swappable' that defines the setting where an alternate model >> > can be defined. Technically, the swappable option *could* be used for >> > any model; however, I'm not proposing that we actually document this. >> > I've implemented it as a generic approach purely to make the internals >> > cleaner -- mostly to avoid needing to make references to auth.User in >> > the model syncdb code, and to make testing possible (i.e., we can do >> > validation tests on a dummy 'swappable' model, rather than trying to >> > munge a validation test for auth.User specifically). >> >> I like the idea of a 'swappable' option, but I can see some potential >> issues with the implementation. I'm one of the developers of Oscar >> (https://github.com/tangentlabs/django-oscar/) and providing a clean >> method to for overriding models has been a major pain point. One of >> our key requirements is that any model in Oscar may be overridden, to >> that end every model has both abstract and concrete versions (much >> like your implementation of AbstractBaseUser and User). >> >> Our current way of handling overrides is for every reference to a >> model in Oscar to use get_model rather than the explicit classname. >> But this does end up causing some ugly things like this: >> >> from oscar.apps.catalogue.abstract_models import AbstractProduct >> >> class Product(AbstractProduct): >> # stuff >> >> from oscar.apps.catalogue.models import * >> >> >> Issues: >> 1) The override model HAS to have the same name as the default model, >> otherwise get_model('catalogue', 'Product') won't work. >> 2) We have to import all the remaining default models after we declare >> our overrides. But this only works because Django's model metaclass >> prevents the default Product replacing the one we've just defined. I >> don't like this because it's a little bit magic. >> 3) You have to remove Oscar's version of the app from INSTALLED_APPS >> and replace it with your own. Actually, technically you don't. If you >> leave Oscar's app installed but put your own one ('foo.catalogue') in >> front of it, you can even get rid of the nasty import * thing - but >> again, more magic. (Aside: you can actually use this approach already >> to override Django's User model, because the metaclass means any >> references to Django's User will be replaced with references to your >> own. ) >> >> I had investigated using a class decorator to handle overrides: >> >> @replace_model('catalogue.Product') >> class MyProduct(AbstractProduct): >> # foo >> >> But this got seriously complicated because the metaclass modifies the >> class before the decorator can be applied, so I was looking into ways >> to sever all the ties with the app cache before I went insane and gave >> up. >> >> Back to my main points... Your swappable option would solve quite a >> lot, in the case of the User model it's ideal. But I'm concerned that >> if people start using it more widely we'd end up having dozens of new >> settings that would get quite silly in the case of a large project >> like Oscar. I think it's important that overrides can be defined in >> the settings file, but I'd also like to see it possible at model >> definition time, either using a decorator (like above) or a Meta >> option like 'replaces'. The risk, of course, is that it means any >> third-party app could override any other model without you necessarily >> being aware of it, not sure how this would be mitigated. >> >> If I've not made much sense let me know, I've always found it hard to >> articulate on this particular topic. >> >> >> Regards, >> Andrew Ingram >> > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/VkctqktqAxMJ. 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.
