Hi all,
While your proposal could solve the repeated creation of migrations due to
dynamic choices, Simon, I don't see how it would solve or prevent the issue
Carl mentioned earlier. Data migrations may need to have the exact choices at
that particular state. Importing the current choices may fail the migration
process on a new database. Furthermore, I think exposing such a feature would
encourage people to use it for the wrong reasons, ending up with hard to debug
bugs.
I favor Andrew's proposal to revisit the white listing of field attributes on a
per-field-instance level, eg:
class MyModel(models.Model):
name = models.CharField(…)
name.migrations_exclude_attributes = {'choices'}
That would be 100% backwards compatible and the autodetector would only need to
check if the changed attribute is in that particular set and ignore the change
in case it is. Since this property only takes effect when used with the current
model, I don't see a need to maintain its presence or value in migrations.
/Markus
On July 17, 2015 11:46:15 AM GMT+10:00, charettes <charett...@gmail.com> wrote:
>Hi everyone,
>
>Here's just an idea from the top of my head.
>
>What if we exposed a `django.db.migrations.Reference`
>that would be a deconstructible proxy to a top level module object.
>It would be initialized with a module name string and the referenced
>object name as a second argument. We could document
>such an object should be returned by fields deconstruct()
>method to opt-in the desired behavior described by Carl.
>
>We already do something similar with the string setting case with
>`django.db.migration.writer.SettingReference` which could be
>a simple subclass of `Reference` that takes a single setting
>name argument instead and pass `django.conf.settings` to it's
>parent initializer.
>
>Thoughts?
>
>Simon
>
>Le jeudi 16 juillet 2015 12:25:50 UTC-4, Carl Meyer a écrit :
>>
>> Hi Andrew and Marcin,
>>
>> On 07/15/2015 05:10 PM, Andrew Godwin wrote:
>> > Django persists every single field attribute change, no matter what
>it
>> > is - this was a deliberate decision as we didn't want to declare
>certain
>> > attributes as "not important for schema" (for example, a subclass
>of
>> > ChoiceField might use an enum column type for the choices and so
>need
>> > that change).
>>
>> There's another reason for this choice: accuracy of the "historical"
>or
>> "frozen" ORM used in data migrations. Even if a field attribute has
>no
>> effect on the database schema, it could have a significant effect on
>the
>> Python-level behavior in a data migration. For instance, it's
>entirely
>> possible that a data migration could use a `get_FOO_display` method,
>> which could certainly break if the choices on that field at that
>point
>> in "migration time" are not correctly preserved in the migrations.
>>
>> > That said, this is definitely a common problem and I'm starting to
>think
>> > we should revisit it - specifically, have field classes themselves
>say
>> > which attributes are not worth making changes for (perhaps combined
>with
>> > greater control by fields over how their schema gets made). This
>isn't
>> > currently possible though.
>>
>> If we do this, I think it should be opt-in and used only by the end
>> developer for unusual cases (like dynamic choices). The default
>should
>> continue to be to preserve all field attributes, including choices,
>for
>> frozen-ORM reasons.
>>
>> Carl
>>
>>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/558942CF-B06A-4538-AEDC-6691B9635A08%40markusholtermann.eu.
For more options, visit https://groups.google.com/d/optout.
