#32344: Allow arbitrary `deconstructible` class properties to participate in
migrations
-------------------------------------+-------------------------------------
Reporter: Ryan Vinzent | Owner: nobody
Type: New feature | Status: new
Component: Migrations | Version: master
Severity: Normal | Resolution:
Keywords: Migrations, | Triage Stage:
ModelState | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by Ryan Vinzent:
Old description:
> 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:
>
> {{{#!python
> 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.
>
> This could enable user-defined `ModelState` in migrations, and allow
> third-party database backends to more easily participate in the
> migrations framework.
New description:
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:
{{{#!python
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.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/32344#comment:1>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.a23a8870f42e51f53b94e5decf7a2897%40djangoproject.com.
