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 in e.g. the schema editor is and how we are generating the indexes in migrations. We might end up with AddIndex, AlterIndex and DeleteIndex operations where CreateModel etc don't know about the index. Introducing some - in any way hacky-ish - "solution" to prevent duplicate index names would probably be deprecated as soon as custom indexes are implemented. That said, touching the migration operations for 1.8 (LTS) in a way that we are not sure yet is are going to stay, and later introducing a new API, seems a bit odd and complicated in terms of backwards compatibility from 1.9? where indexes are introduced. /Markus On Monday, December 1, 2014 6:35:17 PM UTC+1, Tim Graham wrote: > > 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 history, it seems clearer to add tests when fixing > an issue rather than removing a decorator on a test (the contents of the > test won't be easily viewable in the latter case). > > We currently have < 10 tests marked as such in the test suite now. I'd > like to audit them to check their state. Here's a ticket if anyone wants to > help with that: https://code.djangoproject.com/ticket/23943 > > On Monday, December 1, 2014 12:18:31 PM UTC-5, Carl Meyer wrote: >> >> 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-specified types of indexes. For example, maybe >> the >> > user should choose the name, which they should make unique at the app >> > level? Or if not, Django will need to either keep a record of the >> generated >> > index name somewhere, or start renaming indexes to keep them up-to-date >> > with the components in their names. >> >> I think one way or another with the indexes DEP we will need to surface >> the name of an index as an explicit part of its deconstructed >> specification (just like with fields, models, etc). This implies >> probably letting the user pick an explicit name if they want. We could >> also keep the option of using an autogenerated default name, but in that >> case migrations should notice if that autogenerated name changes and >> generate an index-name-change operation. >> >> > What's the best way to proceed with the index name collision ticket >> #23577 >> > <https://code.djangoproject.com/ticket/23577> at this point then? I >> can: >> > >> > 1. re-write my "use migration names in index names" branch >> > < >> https://github.com/tomviner/django/compare/ticket_23577_with_poc_migration_name_fix> >> >> >> > to allow index suffix names passed from migration operations? >> >> What about having the entire index name explicitly passed from the >> operation in migrations (even if for now its always autogenerated >> there)? That seems like maybe a step towards where I think we'll >> eventually need to be. (But take with a grain of salt, you've been in >> this code and I haven't). >> >> > 2. or declare there's no consensus on the solution / we'll wait for >> > Mark's index DEP - in which case, can I submit my tests >> > <https://github.com/tomviner/django/compare/ticket_23577_with_tests> >> as >> > xfails? >> >> Hmm, that's an interesting idea. It's not something we've generally done >> in the past, but it might be better than just letting the tests bit-rot >> as an un-merged PR, later probably needing to be rebased. I'm curious >> what others think of the idea of actually merging xfail tests for >> unfixed bugs? >> >> 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 [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/f54f7b38-f1d1-411d-801f-187c7425346d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
