Re: DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

Thanks for clarifying that Mark. I've updated the ticket mentioning that we'll leave the resolution of the index name collision issue to your DEP. On Monday, 1 December 2014 22:35:49 UTC, Marc Tamlyn wrote: > > I intend the new indexes to have customisable names, and to deconstruct > their name

Re: DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

I intend the new indexes to have customisable names, and to deconstruct their name into the migration. This means that any changes in the name (if the name is autogenerated) would be detected. It should be possible to do renames. It is worth noting that mysql (and sqlite obviously) do not support

Re: DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

Hey folks, I don't like the idea of expected failures either. Given the fact that at one point user defined indexes are going to be introduced, I would consider to delay this issue for now until the DEP has been accepted and is (being) implemented. At that point we know what the underlying API

Re: DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

I'm not in favor of merging expectedFailure tests: * It adds the overhead of time running tests that we know aren't expected to work. * It's more code to maintain (might go stale in the meantime anyway). * An issue might be obsoleted (via deprecation, etc.) at some point. * When viewing commit his

Re: DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

On 11/30/2014 05:54 AM, tomv wrote: > It's important to note that right now, index names are not re-creatable in > retrospect. They rely on the names of models and fields, that are free to > be renamed. So a complete rethink will be needed if introspection can no > longer be used for user-specif

Re: DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

Thanks for pointing out the index improvement DEP Shai, I hadn't seen that yet. It's important to note that right now, index names are not re-creatable in retrospect. They rely on the names of models and fields, that are free to be renamed. So a complete rethink will be needed if introspection

Re: DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

On Thursday, November 27, 2014 9:44:28 PM UTC+1, Shai Berger wrote: > > 1) Using the migration name in the index isn't really "predictable", and > isn't > even completely stable (the name changes when migrations are squashed), > unless > I'm missing something. > I think squashing isn't an i

Re: DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

Hi, Just noted this thread, and I have two points: 1) Using the migration name in the index isn't really "predictable", and isn't even completely stable (the name changes when migrations are squashed), unless I'm missing something. 2) The current practice of identifying indexes by the columns

Re: DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

So one option as you suggest Carl, is to pass a hard coded string into the Operation when it's instantiated in the user's migration file. I've taken a similar approach, starting one level lower, injecting the migration name into database_forwards methods. https://github.com/tomviner/django/comp

Re: DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

On 11/20/2014 11:07 AM, Andrew Godwin wrote: > (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 th

Re: DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

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,

DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

Hi all, At the Django under the hood sprint I picked up #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 n