Is it possible to include an SSIS package file (.dtsx) as part of an EF Core 2.2 Migration, such that the migration installs the package on the target server?
In a Migration, you can include arbitrary SQL scripts with MigrationBuilder.Sql(). And there's a set of stored procedures you can use to deploy an SSIS project or individual packages to the SSIS catalog.
This is one way to handle SQL Server artifacts that aren't directly supported by EF migrations. However, the need to deploy things other than your database schema is a indication that you should strongly consider using SQL Server Data Tools (which has first-class support for SSIS) to manage your SQL Server DevOps, instead of EF Migrations.
Related
I just created an ARM template to create Azure SQL server and Database.
Is there a way to add database schema to this existing ARM template?
If not, what will be the best course of action to specify schema for the resource created through this ARM template.
ARM templates are only used to manage infrastructure resources themselves, not their content. To define the database schema, you will need to run SQL scripts against the database.
I'd recommend using migrations to generate those SQL scripts. While you haven't mentioned in which language the connected application is written, here is documentation on migrations in .NET's Entity Framework Core
The documentation for Entity Framework says to use migration CLI commands to create a database that doesn't exist yet for our EF model, and sync a database when our EF model changes.
Why do we need to explicitly run CLI commands outside our application in order to handle migration?
Can our applications that use EF implicitly handle migration: create a database if it doesn't exist for our EF model and sync a database when our EF model changes?
I had a little experience with Hibernate before, and I didn't hear about migration then. I might be wrong but left with the impression that applications using Hibernate could handle migration implicitly.
You can do either one you want. If you have a formal DevOps deployment process you would normally deploy your database schema then, and the CLI commands are how you do that with Migrations. You can run the migration in the deployment pipeline, or use the CLI to generate the upgrade scripts and run the scripts in the deployment pipeline.
See
Some apps may want to apply migrations at runtime during startup or
first run. Do this using the Migrate() method. . . .
Warning
This approach isn't for everyone. While it's great for apps with a
local database, most applications will require more robust deployment
strategy like generating SQL scripts.
Apply migrations at runtime
So while you would normally apply migrations at runtime on your private developer database, for deployment to shared environments it't often not the best choice.
I am trying to find the best way to synchronize/migrate EF Code First databases from localhost to SQL Azure without using EFCF Migrations. I know that I could use this approach, but I want to look at different, less automagic options.
The following process, or variations of such, is the one I'd like to follow:
Develop locally, letting EFCF build the databse on localhost
Synchronize the local database with the stage database on SQL Azure using some tool
Run tests in the staging environment
Synchronze/migrate the database (local or stage) to the production database on SQL Azure
Using MySQL, this is a breeze. The MySQL Workbench can synchronize a schema model to the database in question, plain and simple. In this case, I don't have a schema model per se, but the database on localhost generated by EFCF could be concidered the schema.
Which tools are available to perform this task? Is it possible to do this using SSMS?
Update: How I did it:
After the tip from Craig to use a Visual Studio 2012 Database Project, I did the following:
Created an empty VS 2012 database project and set its target platform to SQL Azure
Did a new schema compare, source database = local db and target = database project
Updated the target. This brought the database project up to speed
Did a new compare, source= database project and target = SQL Azure stage db
Updated the target. This brought the SQL Azure stage db up to speed
This was exactly what I was looking for
The Visual Studio 2012 database project can do it, I do it all the time.
It's not free, but Red-Gate's SQL Compare would handle the schema replication
So we're using the new SSDT Microsoft released, pretty cool stuff. We are keeping a database project under version control with all the schemas, and an offline database for development and we can later deploy on SQL Azure database. We;re using EF in development, so my question is where would the edmx fit in, should we update the edmx file from the offline database or from the online SQL Azure directly, whats the best practice on this?
I would say that in your case "the production database is the truth", so I would update from SQL Azure. There's no right answer tho really.
Incidentally, in the early betas of SSDT it was possible to have a reference from an EDMX to a SSDT project thus your source code became the truth (which, in my opinion, is preferable) and the EDMX knew it was always working against "the truth". Unfortunately they ditched this feature and there are no signs of it returning.
For the EF to work correctly the EDMX file has to be in-synch with the database you are connecting to. It's hard to answer your question without knowing the development process you follow but I would imagine you use Sql Azure in production and develop against an on-premises database. Therefore one copy of the Edmx file will be used on production server. In the development environment you have a "living" copy of the edmx file that is changed as needed when the local database changes. When you get to the point you when you are ready to ship you deploy your app (include the edmx file) to a production environment that uses Sql Azure.
If, in your development environment, you update the edmx file from the SQL Azure then stuff will break or will not work correctly if the schema of the database in Azure is different from schema of your local database.
I'm using Migrator.NET to manage schema changes on our production environment. Because I've been using EF code-first, all development to the database has been incremental to the code-first classes and no migrations have been applied to the project.
However, I'd like to be able to start using migrations once the project is in a production environment. As the baseline 'up' migration, I'd like to use code-first's database initializer to create the database and prime with default data. However, I'm having problems because the EF context classes and my wrapper classes for EF initializers are in .NET 4, whereas migrator .NET is using .NET 2.
When running the migrator console app, I'm getting 'This assembly is built by runtime newer than the currently loaded runtime...'
Am I expecting to much for this to work? I could use OSQL and create the SQL script on the server, but it would be nice if this worked just as it does in the development environment.
Hmm. Weird. Even if the migratordotnet binary is in .NET 2 you should be able to use it. I worked on a project where we did just this. We used EF Code First to automatically generate the schema if it didn't exist, otherwise we would run the migrations to the existing one (we started creating the migration steps while still in the dev phase).