I want to run some custom Sql after every migration. I was hoping there was a global event or something I could tap into instead of putting my code in each individual migration.
What am I doing? I'm going to traverse the dbcontext via reflection to find enums to dump the key/values into an 'enum' table. The table won't be used anywhere, it's just for reference.
Thanks!
You can override the seed method of the configuration class: http://www.asp.net/web-api/overview/data/using-web-api-with-entity-framework/part-3
Related
I have a code first set of Pocos that work very well. But now I would like to add a few sql views to the DB context. Can this even be done? Or should I make a separate context and use DB First for that?
I would prefer to not use EDMX files and like the simplicity of Pocos.
Yes it is possible and the good thing is that you does not have to create additional context for this. Not even use the awful edmx.
Create ordinaries POCO classes and its corresponding DbSets, and if necessary, add mapping configuration in DbContext to those views as if they were ordinary tables. Then add your migration as usual but for those classes, delete all the migration code from Up and Down methods from the generated Configuration class and that will be all.
I am a newbie in Codefirst and I do not understand how it works correctly.
I created 3 migrations, migration 1..3 via "Add-Migration" command and issued the relative update with "Update Database".
I have a Configuration.cs file in my Migration directory and custom database initializer (I am working on MySQL) I created in order to seed initial data.
I do not know what happens behind the scenes in the production environment where I do not have any database yet.
Who is responsible to create and update the database? Are the migrations executed one after the other?
Can you suggest me how this process works in production and share useful links?
Regards,
Roberto
Assuming you are using Automatic Migrations - All migrations are called one after another, in the sequence in which they were created. Their Up function is called. Afterwards the Seed function on your Configuration class should fire.
Each migration has a sort of a Time-Stamp inside its file name, like this:
if you are creating lots of databases out of a single context class like I do, and you are afraid of not having control over migrations, you can use manual migrations. It is called DbMigrator.
See my/others answer here how to use it.
I've created a new class, and EF will create a migration code when I'll do add-migration in Package Manager Console. Since this table is a classifier, I want to populate it with data and include this data in migration. I cannot use Seed method, since i'll be using my generated migration on production database later on.
Where should I hardcode the values for this table? I can edit the generated migration cs file, but this seems an inelegant solution. Could you recommend more proper place to define the data?
I think if you're goal is to populate your table for development/testing, there's no reason you shouldn't do you data seeding via the Seed method. You could always wrap the seed code for this table with an if block that checks your connection string values.
Edit:
If you plan to populate your table in your production database with the same data, it would certainly make sense to do so in the Up method of that specific migration that creates the table.
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 was wondering if it is possible to override the ObjectContext.SaveChanges() method and write our own sql logic to save the changes made to the entities in the object context instead of relying on Entity Framework to save those changes in the database.
Generally you can do anything you want if you override SaveChanges and do not call base.SaveChanges but you will loose all the stuf EF will do for you. It means you will have to manually browse metadata and map your entities to SQL tables and columns. There will be like writing half the ORM yourselves.
If you just need some little custom logic when persisting entity you can map imported stored procedure to Insert, Update and Delete operations in the entity designer.
In EF4 SaveChanges(SaveOptions) is virtual. You can override this method. MSDN
#Ladislav is correct that a stored proc is one way to do this (+1).
Another way is to write a wrapper provider.