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/b18f6bba-a12e-489e-b370-e062fbfb76e6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
