Scenario:
Existing database with one schema, the transport schema.
2 migration files where version 1 is the initial / base version. Version 2 adds a table to the management schema (but does not create that schema, I want FlyWay to do that).
Using FlyWay API (in Java application)
//...
flyway.setSchemas("transport", "management");
flyway.setInitVersion("1");
flyway.setInitOnMigrate(true);
flyway.migrate();
migration version 2 fails because the management schema has not being created. This succeeds as expected on a clean database.
I get the same problem when executing migrations via the maven plugin.
<configuration>
...
<schemas>
<schema>transport</schema>
<schema>management</schema>
</schemas>
</configuration>
...
mvn flyway:init -Dflyway.initVersion=1 -Dflyway.initDescription="Base version"
mvn flyway:migrate
Seems like if you are using FlyWay with an existing database, you then lose the ability to have FlyWay manage additional schemas.
This is currently not supported. At this point it is an all or nothing deal. Please file a feature request in the issue tracker.
Related
In corda dev mode,
For Example I have created a state with 3 Params, also with Schema for the state.
I have build the project and running it.
Due to the business need to need to 2 more params.
Below are the points I have understood from the corda docs.
Change the state.
Change the schema
Change the contract
Contract and state upgrade flow
I understood the existing states are updated with the new contract constraint.
Will the schema's gets updated by itself during the start of the node by giving {runMigrations=true}
Need help.
Firstly runMigrations property is used only for Corda Enterprise and not for Corda Open Source.
Take a look at the node configs available in enterprise and open source.
https://docs.corda.net/docs/corda-enterprise/4.3/corda-configuration-file.html#database-properties-ref
https://docs.corda.net/docs/corda-os/4.3/corda-configuration-file.html
Performing state upgrades is handled differently in open source and enterprise.
In Enterprise version, the tables are created as liquibase tables and liquibase is used to perform autotmatic database migration.
In Open source, liquibase is not used and tables are created as hibernate entities.
To do a state upgrade, you can add the three new params to your state, build the new jar, replace the old jar with the new one, and hibernate will take care of adding these new columns to the table. One more point on this is that even Hibernate advises not to use Hibernate to modify schema/data migration, so I would recommend you to create your own sql script and run it on the database. (This is done automatically by liquibase in the enterprise)
With corda 4 using signature constraints upgrade is easy, replace old jar with new jar(new jar has to be signed with the same signature used fro signing old jar), start the node. So you do not have to do the complex contract upgrade process.
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'm working on an ASP.NET 5 app that uses Entity Framework 7 with migrations to alter the application's Microsoft Sql Server database.
I'm running into a few issues when I reach the migrations step, and I would like clarification on what the Entity Framework commands migrations add and database update do.
It's my understanding that
> dnx ef migrations add Initial
creates a C# file ending in the name Initial in a folder named Migrations containing code that will create tables based on the application model classes, and
> dnx ef database update
executes the code that will add those changes to the database. However, after the migrations add command, the database has already been created, and the console gives an error when I run the database update command, saying that the tables already exist.
From what I've read on different tutorials, it seems like migrations add shouldn't actually affect the database, and the changes would take place when you run database update, but it doesn't look like that's the case.
Can someone explain what each of these steps are doing and how they fit together? Thanks in advance!
dnx ef migrations add shouldn't create the database. I suspect DbContext.Database.EnsureCreated() is being called somewhere in your application code giving it this effect.
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.
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.