Opened 4 years ago

Closed 4 years ago

#32344 closed New feature (duplicate)

Allow arbitrary `deconstructible` class properties to participate in migrations

Reported by: Ryan Vinzent Owned by: nobody
Component: Migrations Version: dev
Severity: Normal Keywords: Migrations, ModelState
Cc: Simon Charette Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by Ryan Vinzent)

In order to fully take advantage of a custom SchemaEditor class, I need to apply some model level configuration. This configuration can be implemented as a class property on the model, but during the migration, all non-Field class properties are disregarded in the dynamically constructed version of the model's state.

It would be nice if any serializable (or maybe only deconstructible) class property were also able to be included in the migration, so I could add something like this:

class MyPostgresModel(models.Model):
    postgres_options = PostgresOptions(...)

Currently, postgres_options in this case is not passed to the SchemaEditor.create_model() call during the migration, even if it is serializable. The usefulness of a custom SchemaEditor is hindered if it is unable to see this extra model configuration during migrations, as this is usually the only place that a SchemaEditor is invoked. We are already unable to add any additional Meta options, so it seems like there is not currently a natural place for extra table level configuration that can be tracked by migrations.

This could enable user-defined ModelState in migrations, and allow third-party database backends to more easily participate in the migrations framework.

Change History (4)

comment:1 by Ryan Vinzent, 4 years ago

Description: modified (diff)

comment:2 by Mariusz Felisiak, 4 years ago

Cc: Simon Charette added

comment:3 by Simon Charette, 4 years ago

I think this is part of a larger discussion around #5793 so I'll close this one as a duplicate.

The issue here is that we not only need a way to detect these changes but also a way to keep track of them and their evolution through time. If we were to add support for custom attributes addition like #5793 proposes we'd get all of that for free as these options would be included in ModelState.options and ultimately make their way to the schema editor.

comment:4 by Simon Charette, 4 years ago

Resolution: duplicate
Status: newclosed
Note: See TracTickets for help on using tickets.
Back to Top