new op.f() construct not rendered correctly within an Index

Issue #194 resolved
Iuri de Silvio
created an issue

I know it is difficult to fix these bogus indexes, but they are failing my migration.

My upgrade drop my index and create a new one, maybe because names didn't match:

    op.create_index('op.f('ix_residencial_Categoria TV')', 'residencial', ['Categoria TV'], unique=False)
    op.drop_index('ix_residencial_desembolso_tv', table_name='residencial')

The downgrade just revert the change, with the same error. You probably have to escape the quotes or use double quotes instead.

It happens with 0.6.4. The 0.6.3 generates bogus indexes but at least doesn't break with SyntaxError.

Comments (17)

  1. Michael Bayer repo owner

    i dont understand the context. what is:

    op.create_index('op.f('ix_residencial_Categoria TV')', 'residencial', ['Categoria TV'], unique=False)
    

    with the quotes around "op.f()"? autogenerate created that? or you typed that (and if so, why?) ?

  2. Iuri de Silvio reporter

    Yes, the line was autogenerated. I didn't changed the generated script.

    residencial is my table and Categoria TV is the column to be indexed with Column(..., index=True).

  3. Michael Bayer repo owner

    from what I can tell, nothing i did in the fix here should have an impact on bogus indexes being created, the issue I could see is that the "op.f()" directive, which is only there if you're using SQLA 0.9.4 or so with the latest alembic, as well as using anonymously-named indexes (e.g. index=True) which will make use of naming_convention.

    so to that extent I'm not exactly sure why luri reported that it all works now, the "op.f()" should render correctly but rendering happens long after we've determined what's to be added and removed.

    If you are seeing index add/removes that are incorrect, we've already had three releases each of which resolved ever more issues with this new feature and I have no test cases left that illustrate this issue occurring. So would need positive confirmation that if you run Alembic on master the issue of bogus indexes doesn't exist for you, I'm not seeing how that's possible at the moment.

  4. Michael Bayer repo owner

    also @Iuri de Silvio the original error you report seems like either there is a case convention mismatch going on (e.g. mixed case names in your model are sent without quoting and therefore come back as all lower case), or you just changed the name of the column from "desembolso_tv" to "Categoria TV", is that the case?

  5. Iuri de Silvio reporter

    Just to confirm, I never had this op.f() issue again, your fix works nice.

    I know we still have these bogus add/drop indexes, but I can handle that without it and other issues already address this problem.

  6. Iuri de Silvio reporter

    @Michael Bayer I don't remember what exactly my OP code did, I know desembolso_tv and Categoria TV are different fields, probably these add/drop statements are not related. I remember it was some lines with the broken op.f().

    I still have some bogus indexes in this project, probably because my database has some column names with spaces. Do you have an open issue for that or should I open a new one?

  7. Michael Bayer repo owner

    if there's an issue with quoted column names then that could be a new area where fixes are needed here, we probably do not yet have test cases for that. It's more that the casing convention could cause problems if you're on a case-insensitive database like MySQL on certain OS'es.

  8. Iuri de Silvio reporter

    I checked my database and discovered some indexes never existed, maybe because it was migrated with an old version of alembic.

    I wasn't able to reproduce it in a clean environment with SQLAlchemy 0.9.4 and alembic trunk, so it is already fixed.

  9. Log in to comment