Hi Russ, I can see your point on accidentally overriding fields, though I'm not sure I agree. In any other case, such as normal attributes and methods, there is no safety net for overriding attributes either. Any model that would be affected by this change would also raise an error on import without the patch, so existing functional code won't be affected. On the other hand, a new parameter for the field wouldn't be that much of a hassle to implement or work with. I'd be interested to hear what others think about this.
There are more than a few questions <http://stackoverflow.com/search?q=%5Bdjango%5D%5Bdjango-models%5D+override+field+is%3Aquestion> on stack overflow that expect this behaviour, even if the docs specifically mention that it won't work. If users intuitively try to override fields in this manner, I think it would be reasonable to allow this without any explicit arguments. We can always restrict what you can override, at least as the default behaviour, e.g. so that you can only use subclasses of the original field. That would make code that depends on the abstract field less prone to bugs, though subtle bugs can still happen if you e.g. override the max length of a field. This was indeed just a proof-of-concept. That remark was meant more like "it doesn't appear to break everything". Marten Op vrijdag 6 februari 2015 23:48:55 UTC+1 schreef Marten Kenbeek: > > Hey, > > While fiddling with django I noticed it would be trivial to add support > for shadowing fields from abstract base models. As abstract fields don't > exist in the database, you simply have to remove the check that reports > name clashes for abstract models, and no longer override the field. > > This would allow you to both override fields from third-party abstract > models (e.g. change the username length of AbstractUser), and to override > fields of common abstract models on a per-model basis. Previously you'd > have to copy the original abstract model just to change a single field, or > alter the field after the model definition. The first approach violates the > DRY principle, the second approach can introduce subtle bugs if the field > is somehow used before you changed it (rare, but it can happen). > > This patch > <https://github.com/knbk/django/commit/e8347457bccaeab11f9624b01c57824f4511da6c> > adds > the feature. It seems to work correctly when using the models and > creating/applying migrations, and passes the complete test suite. > > What do you guys think about this feature? > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/072149e1-c794-446d-957b-f5fc5df87096%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
