New migration file on migrate for Indexes defined on a Model.

[alexf-bond]

Steps to reproduce:

• Execute aerich upgrade
• Add model level index using indexes list

  class IndexedModel(Model):
  class Meta:
      table = "indexed_model"
      indexes = [Index(fields={"uuid"})]
      uuid = fields.UUIDField()

• Execute aerich migrate and a new migration is generated
• Execute aerich upgrade to apply
• Execute aerich migrate again and notice new migration generated which drops old index and creates a new one

My suspicion is that by not providing a name to the index and relying on Tortoise to generate a random one, the code in migrate is always detecting them as new.

Tested this theory by giving the index a name and still got thet same result. New migration was created again for the same index first with a DROP INDEX and then a CREATE INDEX

Maybe the index hash in the json snapshot for the model isn't unique each time you run migrate?

DROP INDEX "ix_test_uuid";
CREATE  INDEX "ix_test_uuid" ON "indexed_model" ("uuid");

[[package]]
name = "aerich"
version = "0.6.2"

[[package]]
name = "tortoise-orm"
version = "0.19.0"

[VladOsiichuk]

Any updates on this?

[alexf-bond]

Kinda wanna bump this too, I got all my indexes commented out after the initial migration as a work around. It'd be nice to atleast understand if it's a known issue / compromise with the initial implementation.

[fullonic]

@alexf-bond @VladOsiichuk could you try https://github.com/tortoise/aerich/pull/311 and give some feedback? thanks

[alexf-bond]

@fullonic pulled down the branch and added back in my indexes and successfully migrated and upgraded. Upon running migrate again a new file was still generated with a subset of the indexes being dropped and recreated. Also it looks like the indexes being dropped didn't actually exist causing the second upgrade to fail:

tortoise.exceptions.OperationalError: index "idx_accounting__brand_i_e03648" does not exist

Not sure if the hashing / hash detection is working perfectly with these changes. Happy to share the list of indexes / table structure we're using if it'll help debug.

Also is there any possiblity of back porting this to 0.6.2? We haven't upgraded to the new .py version of migrations files just yet.

[FelipeBarrosCruz]

Does anyone have solution for this? Seems like a great database effort to recreate all indexes all times when do a migration.

[alexf-bond]

Thanks for bumping this @FelipeBarrosCruz. I ended up just running migrate with the indexes defined and then just commenting them out with a link to the issue. I tried digging through the code to see why hashes aren't generated correctly with them a while back but maybe i'll revisit again soon :/