Opened 11 years ago
Closed 11 years ago
#21081 closed New feature (duplicate)
Add Leniency to model Meta fields
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
(Apologies for the number of things I've likely done wrong submitting this. First time.)
Currently Django raises a TypeError when it comes across unknown options in a model's Meta. This isn't that great for developers looking to add custom options, as it means having to do a bunch of work to keep Django from seeing those options on instantiation (for example).
I think the reason for the TypeError is to guard against typos biting the developer later down the line. With that in mind, I've attached a simple patch to demonstrate an alternate method of handling this case, which would continue to help guarding against typos while also supporting custom Meta options.
Attachments (1)
Change History (4)
by , 11 years ago
Attachment: | options.diff added |
---|
comment:1 by , 11 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 11 years ago
I don't really think that an unknown Meta attribute should be an error, frankly. But assuming it should be, registration would be a far better solution.
In this specific instance, I'm adding an update_together attribute that defines groups of fields that should always be updated together (this is for what would otherwise be a mixin that updates only changed fields on Model.save(). But I could easily think of a whole bunch of different packages and ideas that would benefit from being able to define their options for a model in that model's Meta.
comment:3 by , 11 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
As noted on Django-developers, this is a duplicate of #5793.
I can't say I'm a big fan of the approach you're describing here - errors are errors for a reason.
If we were going to go down the path of allowing custom Meta attributes, I'd rather see a mechanism that allowed for registration of end-user attributes, rather than kinda-sorta allowing them, and relying on logging to raise the alarm.
It's possible that the GSoC project on refactoring Django's validation framework may provide a way to make this a little easier (handling extra Meta attributes isn't part of this project, but it should fit into the same overall framework).
For the purposes of discussion, it would also be helpful to know what you're looking to store in a custom Meta attribute.