Just chiming in on this; I sat down with Tom to look at this during the sprint, and while we could go to a large amount of effort to try and rename indexes on every rename of a model/field, the problem is solved much more easily by introducing a random element to index names.
This does, of course, make the databases that migrations creates have subtly different schemas; this doesn't matter to Django, as we always look up indexes based on characteristics rather than names, but if you have any examples of where predictable names do matter, please share them! (also, I had an idea on the way back that perhaps we could derive the random element from the migration name, making it different across different migrations so they don't clash but still the same across runs, but I'm not sure how you'd access that from within SchemaEditor) Andrew On Thu, Nov 20, 2014 at 1:56 AM, tomv <[email protected]> wrote: > Hi all, > > At the Django under the hood sprint I picked up #23577 > <https://code.djangoproject.com/ticket/23577> which says, in the general > case: > > 1. For any database object when django creates an associated index > 2. If you rename that object > 3. Then re-create another with the original's name > 4. You get a collision in the name of the associated index > > This applies in the simplest case to renaming any field with > db_index=True, then re-creating another in it's place. But also renaming a > model containing a ForeignKey or indexed field, then re-creating the model. > (All via db migrations) > > The instinctive desire is to rename indexes when renaming objects whose > name was used in the index creation. But speaking to Andrew Godwin, he > feels this would be quite a large challenge, across all our supported > backends. > > The alternative he suggested was to add a random element to all index > names the schema editor creates. This post is seeking to validate that > proposal. > > Note: it's only the names of indexes at issue here, databases keep > everything pointing at the right objects. There's also no issue with > Django needing to access an index via a predictable name, as there's > introspection which grabs indexes according to the objects they work on. > > Bonus question: given the scenario above, can we come up with a source of > index naming that differs after the "parent" object is renamed/re-created, > but which remains deterministic? Something like pulling in a hash of the > whole app model state. Unfortunately, as we aim to output migrations to > sql, we can't have any introspection at migration application time, so > for example no checking for name collisions. > > Cheers, > Tom > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > 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/99246d04-b205-42a6-a389-a0370bea3cd8%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/99246d04-b205-42a6-a389-a0370bea3cd8%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To post to this group, send email to [email protected]. 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/CAFwN1urW_cCq_rdvbvck6Jf96fRuPFULR-aBkv6q0w7cNARD5Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
