none
Bug Report: EF 4.3.1 Code-First Migrations incorrectly detects a change to data model when using many-to-many table RRS feed

  • Question

  • We have determined that the "model-has-changed" logic in EF 4.3.1 is incorrectly detecting a change to the data model when in-fact there has not been any change.

    Specifically, the Diff method of EdmDataModel is not properly handling the generated name of a many-to-many table. Given tables TableA and TableB with a many-to-many relationship between them, the automatically generated name of the many-to-many table can be either TableATableB or TableBTableA.

    And the Diff method detects this name difference as a change to the data model, even though it isn't (at least, not in a functional sense).

    Unfortunatety, we discovered this bug after we had deployed to a production database, and we can no longer delete that database in order to resync it with the Model stored in the _MigrationHistory table.  And we know that it's possible to explicitly specify the name of the generated many-to-many table, but that code change wasn't in-place before we deployed the production database.

    It seems that a simple fix would be to always generate the name of the many-to-many table by concatenating the names of the tables in alphabetic order (eg, always TableATableB, not TableBTableA). 

    But meanwhile, we're going to have to do a manual (and painful) fix-up. 

    DadCat  

     

    Wednesday, July 18, 2012 4:53 PM

Answers

  • Our situation is actually a bit more complex than I described... we have multiple production databases, and some have the name as TableATableB, while others have TableBTableA.

    So we wrote a SQL "rename" script to determine which name was assigned and to rename the production tables to a name of our choosing (and also drop and recreating the constraints). 

    Then in our DbContext's OnModelCreationg override, we specified our chosen table name in WithMany(), so that going-forward we won't continue to have the problem (at least with this particular table). 

    Then we created the migration with add-migration, scripted it with update-database -script and then combined our SQL "rename" script with the SQL generated by update-database (so we would have the all-important Model string). And finally, we manually ran the combined the SQL script against each of the production databases.

    And amazingly, it all worked!   But the underlying problem still needs to be fixed on the MS "side" as soon as possible (as a hotfix????).

    DC 

    • Marked as answer by DadCat Friday, July 20, 2012 7:51 PM
    Friday, July 20, 2012 7:51 PM

All replies

  • Hi DadCat,

    Sorry for the inconvenience caused by this issue. I have added the issue to our internal backlog for investigation.

    To workaround, you may just be able to explicitly tell Code First about the many-to-many table. The way to do that in Code First is to use the .Map fluent API that chains off of WithMany(). As you have already deployed to production, you could just choose the production table name.

    Cheers,

    Andrew.

    Wednesday, July 18, 2012 8:27 PM
  • Our situation is actually a bit more complex than I described... we have multiple production databases, and some have the name as TableATableB, while others have TableBTableA.

    So we wrote a SQL "rename" script to determine which name was assigned and to rename the production tables to a name of our choosing (and also drop and recreating the constraints). 

    Then in our DbContext's OnModelCreationg override, we specified our chosen table name in WithMany(), so that going-forward we won't continue to have the problem (at least with this particular table). 

    Then we created the migration with add-migration, scripted it with update-database -script and then combined our SQL "rename" script with the SQL generated by update-database (so we would have the all-important Model string). And finally, we manually ran the combined the SQL script against each of the production databases.

    And amazingly, it all worked!   But the underlying problem still needs to be fixed on the MS "side" as soon as possible (as a hotfix????).

    DC 

    • Marked as answer by DadCat Friday, July 20, 2012 7:51 PM
    Friday, July 20, 2012 7:51 PM
  • i'm seeing this problem with EF5. did this ever get fixed? it seems like a really bad bug.
    Friday, February 22, 2013 11:02 PM