Re: [Django] #5793: Allow custom attributes in Meta classes
Django
-----------------------------+------------------------------------
Reporter: eikke@… | Owner: nobody
Type: New feature | Status: new
Component: Metasystem | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------+------------------------------------
Changes (by russellm):
* status: closed => new
* severity: => Normal
* resolution: wontfix =>
* easy: => 0
* ui_ux: => 0
* type: => New feature
* stage: Unreviewed => Accepted
Comment:
This ticket was raised on Django-developers in response to a duplicated
report (#21081). The devil is in the details, but I can at least see that
there is a use case here. I share @ubernostrum's concern about Meta
becoming a dumping ground for flags that shouldn't be kept on Meta, but it
doesn't follow that there is no reason why an end-user would want to
define an extension to the built-in set.
--
Ticket URL: <https://code.djangoproject.com/ticket/5793#comment:6>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-----------------------------+------------------------------------
Reporter: eikke@… | Owner: nobody
Type: New feature | Status: new
Component: Metasystem | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------+------------------------------------
Comment (by shai):
On the list, Tim Chase gave this example:
{{{
class MyModel(Model):
class Meta:
...
class MyApp:
secure_fields = ["cc_num", "ssn"]
}}}
The idea was that app-specific properties should be namespaced to avoid
clashes. I think the approach is fine, I just don't see why these classes
need to be in Meta; I see nothing wrong with
{{{
class MyModel(Model):
class Meta:
...
class MyApp:
secure_fields = ["cc_num", "ssn"]
}}}
This leaves the app-specific metadata separate from fields and methods, so
the "API" is clean enough; it avoids clashes reasonably well; and it
requires no changes in Django.
Note that this was the approach taken by Admin at first -- and my
impression (though I wasn't "there" at the time) is that it changed
because Admin classes became too large for comfort as nested classes, not
because the first idea was considered so bad.
I think for most use-cases -- in particular, including the two noted on
the list, marking fields as "to be published" or "to be censored", this
can work well.
The point about extending the ORM stands, but this does not seem to be the
use-case that motivates the current requests.
--
Ticket URL: <https://code.djangoproject.com/ticket/5793#comment:7>
Django
-----------------------------+------------------------------------
Reporter: eikke@… | Owner: nobody
Type: New feature | Status: new
Component: Metasystem | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------+------------------------------------
Comment (by shai):
Replying to [comment:7 shai]:
> The point about extending the ORM stands, but this does not seem to be
the use-case that motivates the current requests.
I have to take that back -- it is true as far as the requests on the
mailing list postings are concerned, but #21081 actually is about
extending the ORM.
--
Ticket URL: <https://code.djangoproject.com/ticket/5793#comment:8>
Django
-----------------------------+------------------------------------
Reporter: eikke@… | Owner: nobody
Type: New feature | Status: new
Component: Metasystem | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------+------------------------------------
Comment (by bronger):
The non-nested `MyApp` doesn't seem to be inherited.
--
Ticket URL: <https://code.djangoproject.com/ticket/5793#comment:9>
Django
-----------------------------+------------------------------------
Reporter: eikke@… | Owner: nobody
Type: New feature | Status: new
Component: Metasystem | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------+------------------------------------
Comment (by bronger):
Forget comment:9, I was wrong.
--
Ticket URL: <https://code.djangoproject.com/ticket/5793#comment:10>
Django
-----------------------------+------------------------------------
Reporter: eikke@… | Owner: nobody
Type: New feature | Status: new
Component: Metasystem | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------+------------------------------------
* cc: litchfield (added)
Comment:
+1 - it's kinda daft to encourage the ORM to be extendable, while at the
same time restricting what Meta options we're allowed
Why not just move DEFAULT_NAMES into the Model class? problem solved, zero
breakage.
--
Ticket URL: <https://code.djangoproject.com/ticket/5793#comment:11>
Django
-----------------------------+------------------------------------
Reporter: eikke@… | Owner: nobody
Type: New feature | Status: new
Component: Metasystem | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
-----------------------------+------------------------------------
Changes (by litchfield):
* cc: litchfield (removed)
* easy: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/5793#comment:12>
Django
Reporter: eikke@… | Owner: nobody
Type: New feature | Status: new
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
-------------------------------------+-------------------------------------
Changes (by timgraham):
* component: Metasystem => Database layer (models, ORM)
* easy: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/5793#comment:13>
Django
-------------------------------------+-------------------------------------
Reporter: eikke@… | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* cc: loic (added)
Comment:
How about an API to register new model options (e.g.
`models.Options.register_option('mptt_manager_name')`).
The `AppConfig.ready()` comes in too late to register this, but
`AppConfig.__init__()` should work.
--
Ticket URL: <https://code.djangoproject.com/ticket/5793#comment:14>
Django
-------------------------------------+-------------------------------------
Reporter: eikke@… | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* cc: jamespic@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/5793#comment:15>
Django
-------------------------------------+-------------------------------------
Reporter: eikke@… | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by James Pic):
Question: is this ticket just about Model.Meta or also for ModelForm.Meta
? /me wondering if another, similar ticket could be opened about
ModelForm.Meta
--
Ticket URL: <https://code.djangoproject.com/ticket/5793#comment:16>
Django
-------------------------------------+-------------------------------------
Reporter: eikke@… | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Adam Chainz):
James I think this ticket is about Model.Meta but whatever the API it ends
up with could be copied over to ModelForm.Meta, so idk if it makes sense
to create a second ticket for that yet
--
Ticket URL: <https://code.djangoproject.com/ticket/5793#comment:17>
Django
-------------------------------------+-------------------------------------
Reporter: eikke@… | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Maxime Vdb):
It would be indeed very useful: I have a custom database backend (for
Redshift) and I would like to support advanced options for this backend
(these options would modify the SQL for table creation for instance).
There is apparently no other way than defining that on the Meta dict (due
to the migration system) but it is not possible to define custom options.
Did you guys agree on the design yet?
--
Ticket URL: <https://code.djangoproject.com/ticket/5793#comment:18>
Django
-------------------------------------+-------------------------------------
Reporter: eikke@… | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Dylan Young):
This would actually enable users to develop on Django much more easily; I
imagine you would get a slew of new ORM developments coming in quite
quickly.
Some thoughts:
1) How to hook into the migration system for database changes? i.e. If I
wanted to add partial indices and have the migrations autogenerate from my
custom Meta option for this. The 'register_option' idea is probably good
for this.
2) How to play nice with migrations for state changes?
--
Ticket URL: <https://code.djangoproject.com/ticket/5793#comment:19>
Django
-------------------------------------+-------------------------------------
Reporter: eikke@… | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* cc: Ryan Hiebert (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/5793#comment:20>
Django
-------------------------------------+-------------------------------------
Reporter: eikke@… | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* cc: Rich Rauenzahn (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/5793#comment:21>
Django
-------------------------------------+-------------------------------------
Reporter: eikke@… | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* cc: Carlos Palol (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/5793#comment:22>
Django
-------------------------------------+-------------------------------------
Reporter: eikke@… | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* cc: Sardorbek Imomaliev (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/5793#comment:23>
Django
-------------------------------------+-------------------------------------
Reporter: eikke@… | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* cc: Gordon Wrigley (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/5793#comment:24>
Django
-------------------------------------+-------------------------------------
Reporter: eikke@… | Owner: nobody
Type: New feature | Status: new
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* cc: omelched (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/5793#comment:25>
Django
-------------------------------------+-------------------------------------
| Hasani Borzadaran
Type: New feature | Status: assigned
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* owner: nobody => Saeed Hasani Borzadaran
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/5793#comment:26>
Django
-------------------------------------+-------------------------------------
Reporter: eikke@… | Owner: Saeed
| Hasani Borzadaran
Type: New feature | Status: assigned
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Old description:
> In some cass it is useful to be able to store meta information on models
> inside the model class. In Django the Meta subclass is used to achieve
> this. Trying to add a custom attribute to a model's Meta inner class
> results in an exception though, thrown from django.db.models.options,
> which does indeed check any valid attribute names and raises an exception
> when unknown names are found.
> Is there any reason for this somewhat strange behaviour, not to allow a
> developer to add non-standard meta information to a model class (which
> can later on be used in eg view code)?
>
> Thanks!
New description:
--
Comment (by Saeed Hasani Borzadaran):
Did I get it right?
The Meta class now receives a series of fixed attributes. We want to make
these features dynamic. Does it mean that the developer can add attributes
to the class?
If yes, can I contribute to this feature in Django 4 or not?
Thanks
--
Ticket URL: <https://code.djangoproject.com/ticket/5793#comment:27>
Django
-------------------------------------+-------------------------------------
Reporter: eikke@… | Owner: Saeed
| Hasani Borzadaran
Type: New feature | Status: assigned
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Mariusz Felisiak):
Saeed, I removed your comment because you remove the ticket description.
Please don't do this.
Django
-------------------------------------+-------------------------------------
Reporter: eikke@… | Owner: Saeed
| Hasani Borzadaran
Type: New feature | Status: assigned
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Loic Bistuer):
Dear Saeed, typically that would be intended for reusable 3rd party apps
to pick up rather than ordinary apps, but yes the idea is not to be
limited to the built-in attributes.
The main challenge is to find an elegant way to register new attributes
(so the system that reports typos still works) and that kicks in at the
right time to be useful, I mentioned above that I suspect
`AppConfig.__init__()` will work but that would have to be checked.
As Dylan mentioned, we also need to see how this interacts with the
migration framework, especially the ORM inside RunPython.
--
Ticket URL: <https://code.djangoproject.com/ticket/5793#comment:28>
Django
-------------------------------------+-------------------------------------
Reporter: eikke@… | Owner: Saeed
| Hasani Borzadaran
Type: New feature | Status: assigned
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Saeed Hasani Borzadaran):
I have studied a lot about the {{{ Meta }}} class.
I disabled the typo section and added my new attribute, but unfortunately,
I didn't get any results.
About {{{ AppConfig.__init__() }}} , I honestly didn't understand and I
need your guidance.
Do you have enough time to explain more? Can you give me an example to
implement it?
--
Ticket URL: <https://code.djangoproject.com/ticket/5793#comment:29>
Django
-------------------------------------+-------------------------------------
Reporter: eikke@… | Owner: Saeed
| Hasani Borzadaran
Component: Database layer | Version: dev
(models, ORM) |
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: assigned => closed
* resolution: => needsinfo
--
Ticket URL: <https://code.djangoproject.com/ticket/5793#comment:30>
Django
-------------------------------------+-------------------------------------
Reporter: eikke@… | Owner: Saeed
| Hasani Borzadaran
Type: New feature | Status: closed
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Saeed Hasani Borzadaran):
Dear Mariusz
This would be a very cool feature to add to Django.
I have enough time to do this and I am very eager to do it.
Can you give me more guidance to get a good result (about connecting
custom attributes to the migration framework)
--
Ticket URL: <https://code.djangoproject.com/ticket/5793#comment:31>
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: new
(models, ORM) |
Severity: Normal | Resolution:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* owner: Saeed Hasani Borzadaran => (none)
* status: assigned => new
--
Ticket URL: <https://code.djangoproject.com/ticket/5793#comment:32>
Django
-------------------------------------+-------------------------------------
| Hasani Borzadaran
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Saeed Hasani Borzadaran):
* owner: (none) => Saeed Hasani Borzadaran
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/5793#comment:33>
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: assigned
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* cc: bcail (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/5793#comment:32>