On Tue, Sep 10, 2013 at 7:34 AM, Marc Tamlyn <[email protected]> wrote:
> I'm not sure either way on this one. I don't want people to get carries > away with Meta, it's not a dumping ground for any old thing you like. That > said, for a developer of a third party library which extends the ORM, the > inability to extend Meta is very problematic. > > I think a balance could be found where strict validation is retained, but > third party apps can add to that validation. The difficulty is the API - if > would be good if it could be done on a per model basis rather than a > global. This should be explicit on behalf of the end user. I'm not sure how > this would work though. > On the basis that this discussion is happening at all, I've just closed #21081 as a duplicate of a newly-reopened #5793. I share James' reservations about this as a feature -- attaching flags to Meta is something I can see being abused in all sorts of ways -- but that doesn't mean there's no legitimate uses for extensions to Meta. For example, the USERNAME_FIELD added in support of custom users should, arguably, be a Meta option -- but there was no way we could add that without making a Meta option available to every class. So - I think custom Meta options are something that should be *possible*. I don't have any particular ideas for how it should be implemented, though. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
