You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Working on MySQL, when I use the unique() method, I get constant diff with my versioned schema, as this method only adds an option on the column, whereas an index is created when actually creating the schema in database. Therefore, I'm wondering whether it would be relevant to have a uniqueIndex() method relying on Doctrine method Table::createUniqueIndex().
If agreed, I will gladly implement it.
The text was updated successfully, but these errors were encountered:
dsavina
changed the title
implement FluidColumnOptions::uniqueIndex()
implement FluidColumnOptions::uniqueIndex() ?
Dec 16, 2020
My guess is that the handling for the custom option "unique" on a column as an index is a specificity of MySQL, but I might be wrong here. I'm all in for rewriting the method to use Table::createUniqueIndex() instead, though we might need to make sure that it does not break compatibility for migrations already using this unique method in existing projects.
I'd say that if a migration has already been applied in production, the change won't impact it. So... yeah.... let's make the change directly in the unique() method!
Working on MySQL, when I use the
unique()
method, I get constant diff with my versioned schema, as this method only adds an option on the column, whereas an index is created when actually creating the schema in database. Therefore, I'm wondering whether it would be relevant to have auniqueIndex()
method relying on Doctrine methodTable::createUniqueIndex()
.If agreed, I will gladly implement it.
The text was updated successfully, but these errors were encountered: