Allowing custom attributes in Meta classes

[Karan Lyons]

Hey all,

I recently opened up a ticket (https://code.djangoproject.com/ticket/21081) that turns out to be a dupe of https://code.djangoproject.com/ticket/5793, both in regards to allowing custom attributes in a model's Meta class.

It was wontfix'd six years ago, the reasoning being that Meta should really only be for setting options related to Django internals. I'm personally of the opinion that at this point Meta is considered the place for *any* options related to a model by developers, and that handling custom options outside of Meta seems against the general Django coding style. Currently you can come up with hacks like https://github.com/karanlyons/django-save-the-change/blob/feature/update-together/save_the_change/mixins.py#L188 to take care of the issue, but this isn't very nice for a number of reasons.

Do we think this should still be a wontfix, and are there any other reasons why?

[Marc Tamlyn]

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.

Marc

--
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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

[Russell Keith-Magee]

On Tue, Sep 10, 2013 at 7:34 AM, Marc Tamlyn <marc....@gmail.com> 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 %-)

[Andy McCurdy]

On Sep 10, 2013, at 7:05 PM, Russell Keith-Magee <rus...@keith-magee.com> wrote:

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

For what it's worth, I've loosely copied Django's "metaclass w/ Meta options" pattern for several projects. In cases where I needed a bit more flexibility, the metaclass looked for a well named attribute on the class that would specify the options class to use. For example:


class Model(object):
# _meta is a ModelOptions instance
__OPTIONS_CLASS__ = ModelOptions


class Foo(Model):
# _meta is a ModelOptions instance, inheriting Model's __OPTION_CLASS__


class User(Model):
# _meta is a UserModelOptions instance that looks
# for a USERNAME_FIELD option
__OPTIONS_CLASS__ = UserModelOptions

[Tim Chase]

On 2013-09-10 21:05, Russell Keith-Magee wrote:
> 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.

One of the areas I've considered trying this is annotating "private"
information about models. The models' Manager class(es) could then
grow methods taking context (such as user information, remote IP,
HTTPS status, etc) and return models that have been sanitized based on
what that context permits ("Joe is a manager on-site, so can see the
full credit-card number and social security number", "Pat is a
non-manager employee visiting from on-site, so can only see the last
4 digits of the credit card number & social", "Ellen is an off-site
user and can only see the last 4 digits of her own credit-card &
social but nobody else's").

For implementation, I'd expect to namespace based on the name of the
app implementing the functionality, so you'd have something like

class MyModel(Model):
class Meta:
...
class MyApp:
secure_fields = ["cc_num", "ssn"]

The indentation might get just a little unwieldy, but namespacing
helps prevent clashes and sensibly be accessible just by chaining
properties:

secure_fields = existing_meta.MyApp.secure_fields

My $0.02

-tkc

[code22]

+1 for this. 

Use case: in one of our projects we had to mark fields allowed for publishing. Using additional meta option would be great for that and I've regretted that it's impossible.