[Django] #32344: Allow arbitrary `deconstructible` class properties to participate in migrations
Django
migrations
-------------------------------------+-------------------------------------
Reporter: Ryan | Owner: nobody
Vinzent |
Type: New | Status: new
feature |
Component: | Version: master
Migrations | Keywords: Migrations,
Severity: Normal | ModelState
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/32344>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
migrations
-------------------------------------+-------------------------------------
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
-------------------------------------+-------------------------------------
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
migrations
-------------------------------------+-------------------------------------
Type: New feature | Status: new
Component: Migrations | Version: master
Severity: Normal | Resolution:
Keywords: Migrations, | Triage Stage:
ModelState | Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* cc: Simon Charette (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/32344#comment:2>
Django
migrations
-------------------------------------+-------------------------------------
Type: New feature | Status: new
Component: Migrations | Version: master
Severity: Normal | Resolution:
Keywords: Migrations, | Triage Stage:
ModelState | Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Simon Charette):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/32344#comment:3>
Django
migrations
-------------------------------------+-------------------------------------
Component: Migrations | Version: master
Severity: Normal | Resolution: duplicate
Keywords: Migrations, | Triage Stage:
ModelState | Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: new => closed
* resolution: => duplicate
--
Ticket URL: <https://code.djangoproject.com/ticket/32344#comment:4>