I am trying to develop my first Entity Framework code-first approach. I am little bit confused regarding Database.SetInitializer<> -
Can I set multiple initializer ? i.e.
Database.SetInitializer<Context>(new CreateDatabaseIfNotExists<Context>());
Database.SetInitializer<Context>(new DropCreateDatabaseIfModelChanges<Context>());
If I use only CreateDatabaseIfNotExists initializer, and later I change database server in connection string, then will the database be created on new server?
No you cannot set multiple initializer. Initializer Only insert data once in database after database created, and database creation script(internally) runs only when you will access any record of any table first time.
And before creating database EF always check first ,the database specified in connection string is present in database server. If database is not there then it will create.
Related
The DropCreateDatabaseIfModelChanges initialisation strategy no longer works in MVC5 with ASP.NET identity.
I'm getting the following error:
The model backing the 'BaseModelContext' context has changed since the database was created. Consider using Code First Migrations to update the database.
What do I do if for now I don't want to use migrations? Shouldn't the fact that I've TOLD it to drop the database that it should then go and do it?
I am stuck trying to figure out how to set the database to run a migration on.
I have created a new empty project and set up Entity Framework using code first. I have all my classes built.
I want to add a new database and run the migrations on this. I have Migrations working but I can't figure out what database they are running on.
Is it possible to set the database you want to use for the migrations?
Multiple DBs for the same context gets a little tricky. But It is possible:
The essence of the problem is how EF decides which connection to use.
It will access instantiate the context without NO PARAMS during migration.
So depending on how that behaves influences you outcome and success.
Start here:
EntityFramework code-first custom connection string and migrations
I'm using EF 4 and MVC in C#,
When my application loads, I would like load create some entities to be added to my database, so where is the best place to add thsi functionality using EF? Global.asax on Start application?
What is a reasonable name convention for the class... BootStrap?
Thanks
If you have existing database you should not include the initialization into your application. The only way how to make this work in existing database is to execute some initialization in Application_Start. The initialization must check existence of every entity you want to insert and insert data only if the entity is not present. Because your database already exists, the initialization logic will have to run every time you restart the application. To avoid this you would also need some flag in the database to mark that initialization was already done (one of inserted entity can be considered as a "flag" but only if the application cannot remove this entity).
EF normally seeds data only when creating database or after database migration.
Edit: If you are creating test data on your test database you should be happy with database recreation each time your model changes (or with migrations) and custom database initializer to seed your data.
I need to configure the database created by Entity Framework Code First MigrateDatabaseToLatestVersion class.
Is it possible to influence the database files parameters like size or maxsize? What interests me in particular, is there a way to add database files?
I assume I need to find the moment where the Entity Framework generates the CREATE DATABASE statement and influence it a bit. As far as I understand, the SqlServerMigrationSqlGenerator class is too late because the database already exists at this point.
Edit: According to comment this doesn't work:
You can just add code based migration using Add-Migration command and modify its Up method to execute Sql("ALTER DATABASE ...") and do what ever you want with your database.
Database is created through DbProviderServices - that is a bridging component between EF and specific database server. ObjectContext exposes operations for creating database and generating database creation script. DbMigrator use database creation operation when you execute Update. It checks that if Database exists and if not it uses ObjectContext.CreateDatabase. So if you want to change the process of creating the database you need to implement your own implementation of the migrator to change the way how Update method generates the database (maybe you just need a decorator which will create a database prior to executing DbMigrator.Update operation).
I want to programmatically create the database create script for my EF 4.3 Code-First database. The database creates just fine using the standard DatabaseInitializer mechanisms, but the following code fails:
using(var dc = new MyContext())
{
var objContext = (IObjectContextAdapter)dc;
var script = objContext.ObjectContext.CreateDatabaseScript();
}
The exception I get is:
The store generated pattern 'Computed' is not supported for properties that are not of type 'timestamp' or 'rowversion'.
I do have a Computed column defined of type "string" but like i said, the database creates fine when created via the built-in DatabaseInitializer. Oddly enough, the resulting schema using this method doesn't actually create a computed column.
As to why I'm doing this, I have a script that runs post-create that drops this column and creates a bonafide computed column. Without specifying the column as computed in the EF mapping, it will attempt to assign that column a value upon inserts, which then fails.
Leaving database creation aside for a moment, setting “Computed” means that EF will not attempt to write the value of that column but will read the value that was (presumably) computer by the server each time the column is queried. From an EF perspective it is valid to have a computed column for any data type.
Now consider database creation from the EF model. EF doesn’t know what to do to create the computed column in the database, and indeed it may not even be possible to do it without triggers in certain databases depending on the type of the column. So in EF4 the decision was made to make CreateDatabaseScript throw in these situations.
However, EF 4.3 and later don’t use CreateDatabaseScript anymore when targeting SQL Server or SQL Server Compact. They instead use the Migrations pipeline. For the Migrations pipeline we decided to take a different approach because we felt that it was wrong for database creation to always throw for what could be a perfectly valid model. Especially considering you could have written your own SQL in the migration that added a trigger or some other mechanism to make the database create a valid computed column.
So this is why you see the database being created by EF 4.3 (but without doing anything to make the column computed) but then you see the same model throw when trying to use CreateDatabaseScript which uses the older, non-Migrations mechanisms.
The way to fix this is to have Migrations create the scripts instead of using CreateDatabaseScript.