Opened 13 days ago
Closed 9 days ago
#35976 closed New feature (wontfix)
Document Options.original_attrs
Reported by: | Tim McCurrach | Owned by: | |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | 5.1 |
Severity: | Normal | Keywords: | |
Cc: | Tim McCurrach, Simon Charette | Triage Stage: | Unreviewed |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | yes | UI/UX: | no |
Description (last modified by )
When a model.Model
class is created the metaclass `pop`s off any Meta
attribue defined on the model before calling super.__new__()
. We do pass it as an argument to the Options
class, and it's stored on the Options
instance, however 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 that this attribute exists.
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.
Change History (6)
comment:1 by , 12 days ago
Cc: | added |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
comment:2 by , 11 days ago
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)
comment:3 by , 11 days ago
Component: | Database layer (models, ORM) → Documentation |
---|---|
Description: | modified (diff) |
Resolution: | wontfix |
Status: | closed → new |
Type: | New feature → Uncategorized |
comment:4 by , 11 days ago
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 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.
comment:5 by , 11 days ago
Description: | modified (diff) |
---|---|
Summary: | Persist original Meta class on Options instances → Document Options.original_attrs |
comment:6 by , 9 days ago
Component: | Documentation → Database layer (models, ORM) |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
Type: | Uncategorized → New feature |
As I feel we could go either way here, I am leaning towards us not adding it to the docs. There are many attributes not documented and I think the use case is fairly niche.
If you disagree and you think we add this to the public API (docs and tests), please raise this on the forum and see if some other folks agree we should add this
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 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 the documented guidelines for requesting features.