Hi Markus,
My proposed solution simply offers a way to opt-in the attribute exclusion
behavior, I didn't mean to solve the whole data migration access to a
particular state issue.
While I see merit in your proposal I cannot understand how it's not also
encouraging people to use it for the wrong reasons, it even looks easier to
do. Correct me if I'm wrong but I don't think it's solving the issue Carl
mentioned either. I also doubt this won't introduce subtle bugs, fields can
behave quite differently if they're missing an attribute. Think of
`default`, `limit_choices_to`, `related_name` and friends.
One last point, even if your proposal is backward compatible it doesn't
help people on 1.7.x and 1.8.x (or third party application that will
support those version for the years to come). If we document that third
party application exposing fields with attribute they want to ignore should
simply return a deconstructible object it would also work with 1.7.x+.
Simon
Le jeudi 16 juillet 2015 23:26:07 UTC-4, Markus Holtermann a écrit :
>
> 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 <chare...@gmail.com
> <javascript:>> 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/ee39a1c3-d987-4f49-b1fc-968a8cf6b0f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
