Reported on the blog by a customer:
http://blogs.msdn.com/b/adonet/archive/2012/05/08/ef5-sample-provider-published.aspx
Hi!
I have encountered a changed behavior in the EF CodeFirst. Since version 4.3 the DbProviderServices.CreateDatabaseScript method is used for database initialization by default, instead of the DbProviderServices.CreateDatabase method. And it seems it just wouldn't fall back if the ProviderIncompatibleException was thrown, so my unit tests fail. My EF provider does not use any script (string) for data operations, so this gives me a great headache currently, because probably I should use ugly workarounds.
What is the reason behind this change? Once someone implements the CreateDatabaseScript method, it is really easy to implement the CreateDatabase method too. The other direction is not that simple, like in my case. This is the implementation of my ProviderServices class, that used to work with EF 4.2.
effort.codeplex.com/.../6d548c5eab06
Pawel
28 Jun 2012 5:08 PM
#
@Tamas Flamich: In EF 4.3 support for Migrations was added. Migrations require __MigrationHistory table to work correctly. What the code does is first creating the database by calling then DbProviderServices.CreateDatabase() method and then the __MigrationHistory table is added by executing sql statement returned from ObjectContext.CreateDatabaseScript(). I will add a work item to handle the ProviderIncompatibleException exception. For now you could work around the problem by recognizing whether the CreateDatabaseScript is called for Migrations based on StoreItemCollection passed to the CreateDatabaseScript method and either return a hardcoded Sql statement or do nothing. Also, note that this behavior is also present in EF5.
http://blogs.msdn.com/b/adonet/archive/2012/05/08/ef5-sample-provider-published.aspx
Hi!
I have encountered a changed behavior in the EF CodeFirst. Since version 4.3 the DbProviderServices.CreateDatabaseScript method is used for database initialization by default, instead of the DbProviderServices.CreateDatabase method. And it seems it just wouldn't fall back if the ProviderIncompatibleException was thrown, so my unit tests fail. My EF provider does not use any script (string) for data operations, so this gives me a great headache currently, because probably I should use ugly workarounds.
What is the reason behind this change? Once someone implements the CreateDatabaseScript method, it is really easy to implement the CreateDatabase method too. The other direction is not that simple, like in my case. This is the implementation of my ProviderServices class, that used to work with EF 4.2.
effort.codeplex.com/.../6d548c5eab06
Pawel
28 Jun 2012 5:08 PM
#
@Tamas Flamich: In EF 4.3 support for Migrations was added. Migrations require __MigrationHistory table to work correctly. What the code does is first creating the database by calling then DbProviderServices.CreateDatabase() method and then the __MigrationHistory table is added by executing sql statement returned from ObjectContext.CreateDatabaseScript(). I will add a work item to handle the ProviderIncompatibleException exception. For now you could work around the problem by recognizing whether the CreateDatabaseScript is called for Migrations based on StoreItemCollection passed to the CreateDatabaseScript method and either return a hardcoded Sql statement or do nothing. Also, note that this behavior is also present in EF5.