[Django] #35976: Persist original Meta class on Options instances

[Django]

#35976: Persist original Meta class on Options instances
-------------------------------------+-------------------------------------
Reporter: Tim McCurrach | Type: New
| feature
Status: new | Component: Database
| layer (models, ORM)
Version: 5.1 | Severity: Normal
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------
When a `model.Model` class is created
[https://github.com/django/django/blob/ded485464214a3f69b64402b7d82221279f80008/django/db/models/base.py#L112
the metaclass `pop`s off] any `Meta` attribue defined on the model
[https://github.com/django/django/blob/ded485464214a3f69b64402b7d82221279f80008/django/db/models/base.py#L122
before calling] `super.__new__()`. We do
[https://github.com/django/django/blob/ded485464214a3f69b64402b7d82221279f80008/django/db/models/base.py#L145
pass it as an argument] to the `Options` class, and
[https://github.com/django/django/blob/ded485464214a3f69b64402b7d82221279f80008/django/db/models/options.py#L136
it's stored] on the `Options` instance, however
[https://github.com/django/django/blob/ded485464214a3f69b64402b7d82221279f80008/django/db/models/options.py#L232
this is then deleted] whilst the `Options.contribute_to_class` class is
called.

As far as I can tell, there is no reason why it is important to delete the
original data stored in the class defined on the original model.
Admitedly, perhaps it could be stored with a better name to indicate it is
a non-functional reference to the original `Meta` class.
`instance._meta.meta` probably doesn't make much sense, but
`instance._meta.original_meta` might be more appropriate.

=== Motivation for feature request ===

The motivation for this came change is born out of a desire to write a
check that `db_table` is explicitly defined on all my models (even if it
matches the default value that django would apply). I can write checks
that require things like `ordering` is defined (or not defined) on a
model. The problem with `db_table` is that defaults are applied when
`contribute_to_class` is called. This means we need a reference to the
underlying original Meta data. This is not currently possible without
subclassing the metaclass (`ModelBase`) which is a step further than would
be ideal imo.

=== The fix ===

The fix should be very simple. We would just need to remove (or adapt) the
line of code linked above which deletes the meta-class. (We could maybe
use a better name than `original_meta`!!)
--
Ticket URL: <https://code.djangoproject.com/ticket/35976>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

[Django]

#35976: Persist original Meta class on Options instances
-------------------------------------+-------------------------------------

Reporter: Tim McCurrach | Owner: (none)
Type: New feature | Status: closed
Component: Database layer | Version: 5.1
(models, ORM) |
Severity: Normal | Resolution: wontfix

Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Sarah Boyce):

* cc: Simon Charette (added)
* resolution: => wontfix
* status: new => closed

Comment:

Hi Tim,

I was trying to understand if this was a new feature or a cleanup, but as
you want a new attribute that you can rely on (and so would need to be
documented), it makes sense that this is a new feature. Can you raise this
on the [https://forum.djangoproject.com/c/internals/5 Django Forum] and
see if others are in favor of the idea and if there are any concerns
around doing this?

If the community agrees with the proposal, please return to this ticket
and reference the forum discussion so we can re-open it.
For more information, please refer to
[https://docs.djangoproject.com/en/stable/internals/contributing/bugs-and-
features/#requesting-features the documented guidelines for requesting
features].
--
Ticket URL: <https://code.djangoproject.com/ticket/35976#comment:1>

[Django]

#35976: Persist original Meta class on Options instances
-------------------------------------+-------------------------------------
Reporter: Tim McCurrach | Owner: (none)
Type: New feature | Status: closed
Component: Database layer | Version: 5.1
(models, ORM) |
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Tim McCurrach):

Hi Sarah,

Thanks for the speedy reply. Yes, I wasn't sure if it was a new feature or
clean-up either, but ended up thinking the same as you.

I started writing a post in the django forum, but as I was doing so,
reading the code again I realised the feature I was asking for actually
(more or less) already exists!!
(https://github.com/django/django/blob/c075d4c2c8cef3c9b28180c749d421c63544a9dd/django/db/models/options.py#L189-L191
)

My only question now, is should we document this? I'll re-open the ticket
as a documentation ticket and edit the description. If you think it's a
good idea to document it, I'd be happy to add something.

(Should I still start a thread on the django-forum for this, as even
though there are no code-changes I suppose this would be a new feature
from an external perspective. Please do let me know. Thanks)
--
Ticket URL: <https://code.djangoproject.com/ticket/35976#comment:2>

[Django]

#35976: Persist original Meta class on Options instances

-------------------------------+--------------------------------------

Reporter: Tim McCurrach | Owner: (none)

Type: Uncategorized | Status: new
Component: Documentation | Version: 5.1
Severity: Normal | Resolution:

Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0

-------------------------------+--------------------------------------
Changes (by Tim McCurrach):

* component: Database layer (models, ORM) => Documentation
* resolution: wontfix =>
* status: closed => new
* type: New feature => Uncategorized


Old description:

New description:

When a `model.Model` class is created
[https://github.com/django/django/blob/ded485464214a3f69b64402b7d82221279f80008/django/db/models/base.py#L112
the metaclass `pop`s off] any `Meta` attribue defined on the model
[https://github.com/django/django/blob/ded485464214a3f69b64402b7d82221279f80008/django/db/models/base.py#L122
before calling] `super.__new__()`. We do
[https://github.com/django/django/blob/ded485464214a3f69b64402b7d82221279f80008/django/db/models/base.py#L145
pass it as an argument] to the `Options` class, and
[https://github.com/django/django/blob/ded485464214a3f69b64402b7d82221279f80008/django/db/models/options.py#L136
it's stored] on the `Options` instance, however
[https://github.com/django/django/blob/ded485464214a3f69b64402b7d82221279f80008/django/db/models/options.py#L232
this is then deleted] whilst the `Options.contribute_to_class` class is

called. The attributes from the meta value are stored on a
`original_attrs` attribute however. It might be a good idea to document
this!!

=== Motivation for the documentation ===

The motivation for this came change is born out of a desire to write a
check that `db_table` is explicitly defined on all my models (even if it
matches the default value that django would apply). I can write checks
that require things like `ordering` is defined (or not defined) on a
model. The problem with `db_table` is that defaults are applied when
`contribute_to_class` is called. This means we need a reference to the

underlying original Meta data. The `original_attrs` attribute is perfect
for this, but as far as I can tell it isn't documented anywhere.

--
--
Ticket URL: <https://code.djangoproject.com/ticket/35976#comment:3>

[Django]

#35976: Persist original Meta class on Options instances
-------------------------------+--------------------------------------
Reporter: Tim McCurrach | Owner: (none)
Type: Uncategorized | Status: new
Component: Documentation | Version: 5.1
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------+--------------------------------------

Comment (by Tim McCurrach):

Just to play devils advocate here:

Reading the comment above where it is defined, documenting the attribute
would potentially represent a change in purpose for the variable. At the
moment it exists to aid with serialisation of the model, which would be
distinct to a reference for users to take advantage of.

Also, looking at [https://docs.djangoproject.com/en/5.1/ref/models/options
/#read-only-meta-attributes the docs], there are currently only 2
attributes listed under read-only attributes, and there are definitely
others defined on `Options` that could go there. So there is also a
question of precedent here.

None-the-less, I think it would be quite a useful thing to know about. I
could go either way on this.
--
Ticket URL: <https://code.djangoproject.com/ticket/35976#comment:4>