I am well on my way to utilizing EF7 CodeFirst with SQLite...but really want to employ DB Migrations at runtime. This is a desktop application (Click-once deployment) meant to sync with a main database when connection is available, and provide offline data when no connection is present.
I have pulled down the nuget pre-release versions and all is working, except I cannot find any documentation of how to apply the migrations at runtime. I can successfully Add-Migrations and manually Apply-Migrations...but need a way to programatically Apply-Migrations at runtime.
I've also browsed the EF7 open-source project, but could not get anywhere there.
Versions I'm using: Latest Pre-release as of 9/15/2015
EntityFramework.Sqlite v7.0.0-beta7
EntityFramework.Relational v7.0.0-beta7
EntityFramework.Commands v7.0.0-beta7
...et al...you get the picture.
I am asking for help to apply runtime migrations...or what is the documented/recommended path for programatically maintaining a local/embedded db using EF7 CodeFirst SQLite?
UPDATE:
I went back to EF6 with SQLite but then found out that there is not SQLMigrationGenerator for SQLite.
EDIT:
I believe ApplyMigrations() method referenced in one of the notes has been deprecated. Searching the repository, there is no reference to "ApplyMigrations".
Today you can invoke the extension method Migrate on the DatabaseFacade.
This method is only available when the using Microsoft.Data.Entity statement is present. It comes from the RelationalDatabaseFacadeExtensions class that is part of the EntityFramework.Relational package.
Still have to find out how to migrate up and down from the API.
Related
How do I update the database for production? I've moved the connection string secrets out of the application. Our CI/CD pipeline handles the token replacement within the connection string "template" that remains in the appsettings, and developers won't have production database access.
I had expected to use automatic migrations, only to discover today that Microsoft eliminated that for EF Core.
Will I have to, every time, temporarily overwrite the connection string that normally specifies my local dev copy of the database? It seems that way, but it also seems very janky process to me, so I wonder if I'm missing something.
There seem to be a confusion of what automatic migration means.
Migrations consist of two parts:
generation from the model
applying to the database.
Migration generation in turn could be two types:
automatic - at runtime, current model is compared to model produced by the last migration, and if there are changes, it generates an automatic migration code.
manual - migrations are generated at design time using the design time tools (Add-Migration command). The auto-generated code can be modified. Modified or not, the migration is stored along with the application code.
Regardless of how migrations are generated, they can be applied at design time using the tools (Update-Database command) and/or at runtime.
What EF6 supports and EF Core have removed is the auto-generation. EF Core migrations cannot be generated at runtime - they must be generated at design time and stored with the application code.
Applying them at runtime is achieved with Migrate method called from some application startup point:
dbContext.Database.Migrate();
For more info, see Migrations and Apply migrations at runtime EF Core documentation topics.
I am working on a ASP.NET Web Forms project which is expected to experience lots of database changes even after deployment.
Our preference was to use Entity Framework 5, and the Database First design paradigm. However, since we have to make lots of changes to the database even after deployment, if I use database first approach, then every time I update my database, I will have to delete my entire model and regenerate it. Is there any best practices to make this process less painful?
You should use Code First, so that you can use Migrations.
More specifically I'd use manual Migrations.
With manual Migrations you can create Migrations at any point in time. A migration has the following information:
a snapshot of the current model
a set of "instructions" to upgrade from the previous migration
a set of "instructions" to downgrade to the previous migration
Apart from the necessary Migrations, you should add a new Migration when you deploy your app. For example, you can create a migration called "Version 1.0", when you deploy the version 1.0 of your app.
When you finish each new stable version, you simply add a new migration, for it, like "Version 1.1" or "Version 1.2".
The interesting part of migrations shows up when you have a deployed application version and you need to upgrade (or downgrade) to a new version.
There are commands that let you upgrade (or downgrade) a DB from one particular version
to another particular version. You can do it directly specifying a connection to the DB, or create a SQL script which will apply the changes to the DB. For example, if you deployed the version 1.0 in a customer server, and you need to upgrade the software to version 1.2, you can do this:
Update-Database -SourceMigration "Version 1.0" -TargetMigration "Version 1.2"
-Script
This will create a SQL script which can be run on the DB to upgrade from version 1.0 to 1.2.
If you need help about any of the Migrations commands, simply type:
get-help Update-Database -full
(Update-Database is a command name, you can specify any other like Add-Migration)
It's possible that you need to specify the project where the model is in, the connection string name, the name of the project with the .config file or some other things, depending on the specified parameters, and the structure of the projects in your solution.
To get more info on migrations, read MSDN EF Code First Migration.
NOTE ADDED IN EDITION: there is a new DB initializer that can automatically migrate to the latest version when the application runs. I've worked in a real application, and it works like a charm.
ALTERNATIVE SSDT
If you don't want to follow the advice, you can use SQL Server Data Tools (which can be installed inside VS, or work as an independente application, depending on the version you're using).
The idea of this tool is that you can compare projects (which are DB schema snapshots) to existing DBs, and generate the scripts to change the DB to match the schema in the project. (In fact you can compare any combination ofr project and DB)
If you keep versions of your project in a CVS you can even check the changes from one verison of the project to other version of the project.
NOTE ADDED IN EDITION: a SSDT project is a set of scripts that can build the whole DB, including all the objects in its schema. You can create it from an existing DB or viceversa. Then you can keep comparing any combination of DBs and SSDT projects, as soruce or target, and create an apply the scripts neccesary to change each particular object which has changes. (The scripts are created to change the target so that it looks like the source, but you can swap source and target easyly)
This is an alternative solution, but Migrations are much more powerful because you can customize them, for example to fill a "master table" when creating it, to set the initial value of a new column, and so on. If you use SSTD you'll have to do all of that by hand, and carefully keep track of it. So I highly recommend using Migrations.
I need to be able to perform all of the available functions that the Package Manager Console performs for code first DB migrations. Does anyone know how I could accomplish these commands strictly through user defined code? I am trying to automate this whole migration process and my team has hit the dreaded issue of getting the migrations out of sync due to the number of developers on this project. I want to write a project that the developer can interact with that will create and if need be rescaffold their migrations for them automatically.
PM is invoking through PowerShell and PS cmdlets (like for active directory etc.)
http://docs.nuget.org/docs/reference/package-manager-console-powershell-reference
The Package Manager Console is a PowerShell console within Visual
Studio
...there is essentially very little info about this - I've tried that before on couple occasions and it gets down to doing some 'dirty work' if you really need it (not really sure, it might not be that difficult - providing you have some PS experience)
Here are similar questions / answers - working out the PS comdlets is pretty involving - in this case it has some additional steps involved. And PS tends to get very version dependent - so you need to check this for the specific EF/CF you're using.
Run entityframework cmdlets from my code
Possible to add migration using EF DbMigrator
And you may want to look at the source code for EF that does Add-Migration
(correction: this is the link to official repository - thanks to #Brice for that)
http://entityframework.codeplex.com/SourceControl/changeset/view/f986cb32d0a3#src/EntityFramework.PowerShell/Migrations/AddMigrationCommand.cs
http://entityframework.codeplex.com/SourceControl/BrowseLatest
(PM errors also suggest the origins of the code doing the Add-Migrations to be the 'System.Data.Entity.Migrations.Design.ToolingFacade')
If you need 'just' an Update - you could try using the DbMigrator.Update (this guy gave it a try http://joshmouch.wordpress.com/2012/04/22/entity-framework-code-first-migrations-executing-migrations-using-code-not-powershell-commands/) - but I'm not sure how relevant is that to you, I doubt it.
The scaffolding is the real problem (Add-Migration) which to my knowledge isn't accessible from C# directly via EF/CF framework.
Note: - based on the code in (http://entityframework.codeplex.com/SourceControl/changeset/view/f986cb32d0a3#src/EntityFramework.PowerShell/Migrations/AddMigrationCommand.cs) - and as the EF guru mentioned himself - that part of the code is calling into the System.Data.Entity.Migrations.Design library - which does most of the stuff. If it's possible to reference that one and actually repeat what AddMigrationCommand is doing - then there might not be a need for PowerShell at all. But I'm suspecting it's not that straight-forward, with possible 'internal' calls invisible to outside callers etc.
At least as of this post, you can directly access the System.Data.Entity.Migrations.Design.MigrationScaffolder class and directly call the Scaffold() methods on it, which will return you an object that contains the contents of the "regular" .cs file, the "Designer.cs" file and the .resx file.
What you do with those files is up to you!
Personally, I'm attempting to turn this into a tool that will be able to create EF6 migrations on a new ASPNET5/DNX project, which is not supported by the powershell commands.
I'm learning Symfony2 and have just learnt about doctrine:migrations. It sounds like a great way of 'versioning' the database schema and deploying new schemas in production.
I've also been reading about data fixtures for development. Is there any way to version these in a similar fashion as the schema migrations, or should I just use GIT?
Migrations' versions have to be kept under version control. If GIT is your SCM, then it's fine.
I am currently using SubSonic (2.2 and 3) for some ASP.NET projects and have managed to get them working with SQL Server (using ActiveRecord). However, I also want to know how to set it up with other (open source) databases, e.g. PostgreSQL and SQLite. This is so I can use it on a web host without SQL Server on. The providers I have found are:
PostgreSQL: Npgsql
SQLite: System.Data.SQLite or Mono.Data.SqliteClient (if it works with Microsoft.NET)
Anyone have any experience with SubSonic know how to do this (some sample demo would be good - just a basic primer on querying would be fine)? Non-ASP.NET MVC though (not got into it yet). I have only basic knowledge of SQLite (basically using SQLite Manager in Firefox and querying it via PHP Data Objects) and have not used Postgresql, but assume it would be more scalable than SQLite.
For version 3
PostgreSQL: There aren't any templates for postgres at the moment so you'd need to create the templates yourself
SQLite - The steps should be as follows:
Add a reference to System.Data.SQLite
Look in the TemplateProviders folder you'll find a SQLite.ttinclude which you'll need to drop into your project instead of SQLServer.ttinclude.
Change the .tt files that reference SQLServer.ttinclude to reference SQLite.ttinclude instead.
This is so I can use it on a web host without SQL Server on.
With the release of SQLExpress dont all hosts offer this? (I only use dedicated server so I have no direct experiance with this)
In response to your question.
SQLite - http://codefornothing.wordpress.com/2007/07/19/sqlite-data-provider-for-subsonic-part-2/
Postgre: Doesnt look as simple,
Subsonic postgreSQL Template
PostgreSQL via subsonic
Good luck.
In short, Subsonic only support few database only NOT ALL ( that what their claimed :( ). Try nHibernate, support most of the database.