[Closed] All Indexes are recreated with description suffix

Question

I have created a new Skipper project from existing symfony2/doctrine2 entities.
I have then exported back to the Symfony2 project.
I then ran 'php app/console doctrine:migrations:dif' to generate doctrine migrations.
It has recreated all indexes applying a suffix to the name, eg

$this->addSql('ALTER TABLE Basket DROP INDEX UNIQ25EA554DA76ED395, ADD INDEX IDX25EA554DA76ED395 (user_id)');

I don't want this as I need to update a live database and this could cause problems. How do I prevent these name changes please?

Thanks

Comments

Are there any differences in original and exported/updated doctrine2 schema definitions?

---

Yes there was a difference in the schema definitions. I've managed to get rid of the change on this one, but I still have differences being generated for others such as

@ORM\JoinTable(
     *     name="Category_SubCategory",
     *     joinColumns={@ORM\JoinColumn(name="category_id", referencedColumnName="id")},
     *     inverseJoinColumns={@ORM\JoinColumn(name="subcategory_id", referencedColumnName="id")}
     * )

where as I only want

@ORM\JoinTable(
     *     name="Category_SubCategory"
     * )

Otherwise the indexes get regenerated with different names

---

The problem with having these extra unwanted annotations is that I then get unwanted migrations like this:

addSql('ALTER TABLE Category_SubCategory DROP FOREIGN KEY FK_DF515BA912469DE2');
        $this->addSql('ALTER TABLE Category_SubCategory DROP FOREIGN KEY FK_DF515BA95DC6FE57');
        $this->addSql('ALTER TABLE Category_SubCategory ADD CONSTRAINT FK_DF515BA912469DE2 FOREIGN KEY (category_id) REFERENCES Category (id)');
        $this->addSql('ALTER TABLE Category_SubCategory ADD CONSTRAINT FK_DF515BA95DC6FE57 FOREIGN KEY (subcategory_id) REFERENCES SubCategory (id)');

Answer 1

Thanks for additional info about this issue. Unfortunately currently it isn't possible to export join table without join/inverse-join columns.

I fully understand that in your case it's necessary to update database schema but unfortunately it's not possible to do that in other way. Skipper exports schema definitions in full, unambiguous and recommended format and obviously it is causing this behaviour in case your schema previously didn't use full definition.