Issue with migrations on MariaDB 10.2 #320
Comments
|
Yes, this was by design. rename operations only works with 5.7+. We do not want to drop and re-create. |
|
Okay, so the driver basically supports MYSQL 5.7, with no intention to support older versions of MYSQL nor mariadb? |
No The migration operation is here in MySqlMigrationsSqlGenerator.cs A server version flag needs to be added here in ServerVersion.cs for Then the migration option needs to check Happy to accept it as a PR or we can fix it. On a side note it'd be good to add MySql 5.6 and MariDB 10.3 to our TravisCI setup to catch stuff like this |
|
@caleblloyd thanks for clarifying, I'll try to look into it tomorrow if I get the time. |
|
@caleblloyd I see that you tagged it up for the 2.0 release - would it be possible to backport it to the 1.1 series? Because we kind of need the feature for a project running on 1.1 that can't be upgraded to the preview. |
|
@nover Sorry, we don't have an LTS plan for 1.1, maintaining different versions is a huge program, and we only have 2 people maintaining this project. Besides, for this issue, it was just an enhancement, not a bug. |
|
@kagamine Fair enough - what if I make two PRs? One based off master for 2.0 and one based off the 1.1.2-rtm branch? |
|
should push to 1.1.3 branch |
|
Sure we'll accept a PR and push a 1.1.3 prerelease for you! |
|
Okay PR ready for version 2.0: |
|
Backport of changes for 1.1: |
|
Excuse me, I have the issue with RENAME INDEX, and apparently this fix would solve that. But I can't understand how I should use it. Thanks for any help! |
|
My version string on the server is: But the index renaming is still not supported: Can I force the server version somehow? |
|
See ServerVersion in Configuration Options wiki. |
Steps to reproduce
On an existing EF model with a foreign key to one table, change that foreign key to another table - this caused EF to create a "RENAME INDEX" in my case as the column name changes.
The issue
When renaming indexes MySQL 5.7 introduced a new nice keyword
RENAME INDEX TO- however, Mariadb 10.2 does not support this, so the generated migration fail.I was hoping that the MySQL connector could see / guess that it's not talking to MySQL 5.7 and create a migration that would apply cleanly - something like
DROPandCREATEindex though it is a slower.Doctrine - an ORM for PHP had a similar issue:
doctrine/migrations#196
Further technical details
MySQL version: MariaDB 10.2.6
Operating system: Windows 10 with database via Docker Compose
Pomelo.EntityFrameworkCore.MySql version: 1.1.2
Now I know that the driver says it is MySQL compatible, but given that MariaDB is so close to being binary compatible with MySQL I was hoping you would look into fixing this.
The text was updated successfully, but these errors were encountered: