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 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.
