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 > <rus...@keith-magee.com<javascript:>> > 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/-/AKe1T5bePTkJ. To post to this group, send email to django-developers@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.
