Is it possible run a repeatable migration only when a specific target version is exceeded?
For example,
Current version: 0.7.0
V0.7.0__cars.sql
CREATE TABLE cars (
id INT NOT NULL PRIMARY KEY,
license_plate VARCHAR NOT NULL,
color VARCHAR NOT NULL
);
R__Blue_cars.sql
CREATE OR REPLACE VIEW blue_cars AS SELECT id, license_plate FROM cars WHERE color='blue';
Now if i run this migration in development, there are no problems. However if I try to migrate to a specific target on my staging/production instance, I run into trouble.
flyway -target=0.5.0 migrate
This migration includes R__Blue_cars.sql
Ideally I would want that repeatable migration to run for the first time only if target >= 0.7.0
Flyway repeatable migrations do not have a version. Therefore by design, repeatable migrations cannot be selectively applied based on a target version. Also, repeatable migrations are applied only after all versioned migrations are done.
Related
Upgraded our application from .Net Core 3.1 to 5.0.6, and everything was working using an existing database. If I drop the database and run the migrations I get this error:
There is no entity type mapped to the table 'UserClause' used in a data operation. Either add the corresponding entity type to the model or specify the column types in the data operation.
The UserClause table no longer exists it gets renamed in the migration that fails, but if this particular migration completed it would be the Agreement table, but it throws on this migration due to a missing entity type, which definitely doesn't exist either since this was originally run over a year ago.
Anyone know why the migration would be looking for an entity type, and how to resolve the issue? Doesn't seem like this should be checking for entities while it runs the migration.
Looks like in EF Core 5 that some of our migrations where there was a table rename had to have their update or insert statements moved to be after the rename of the table, otherwise you would get this error. Once they were after the table renaming and the table name for the update/insert were changed to the renamed table name everything worked.
In my case, i've to add the schema parameter to the InsertData function, like "dbo"
I have an issue where I have an existing database which where I have mapped over only certain entities to use with EF Core (the DB has 100s of tables and I dont want classes for all of them.
I scaffolded the starting stage like this
dotnet ef dbcontext scaffold .. etc etc
Where I specified specific tables with the connection string.
I then created an initial migration to snapshot the starting stage with
dotnet ef migrations add Initial
I now want to add a new table based on a new entity. So I created a second migration using
dotnet ef migrations add NewTable
But when i run this using..
dotnet ef database update NewTable
It attempts to add the tables in the initial migration! because I havent ran that migration, so I have no records in __EFMigrationsHistory. But I dont want to run the first migration as I already have the tables which were scaffolded! Initial was just to create a snapshot which is what I thought you have to do.
So is there some way to make it think Initial has already been run? By putting something in
__EFMigrationsHistory? Then I can run the NewTable migration without getting "object already exisits".
Thanks
It ran my latest NewTable migration fine after I removed the previous one, otherwise it was still trying to add objects from the initial migration resulting in "Object already exists".
I find this strange as the statement
'dotnet ef database update NewTable'
specifies which migration I wanted to run, and shouldn't run initial again. Anyway this fix worked fine.
How does Flyway handle multiple schema dependencies?
Ie
V1_CREATE_TABLE.sql in SCHEMA_A
V2_CREATE_VIEW.sql in SCHEMA_B (based on table in schema A)
Is it possible to ensure that V1 is created before V2?
It is also possible to get into a cross dependency. For example say V3_CREATE_VIEW_2.sql in SCHEMA_A (based on view in schema B). How do we ensure that dependency?
Flyway will execute the scripts in order based on their version numbers. If you want a single instance of Flyway to manage objects in multiple schemas, you must prefix the object names in the migration scripts.
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 work only with one schema on flyway.
but when i use
Flyway flyway = new Flyway();
flyway.setDataSource(ConectorWatson);
flyway.setSchemas("db_watson");
flyway.migrate();
the flyway create one schema_version on my pulic schema and db_watson.
can i only use db_watson ?
tks
Flyway only creates a schema_version table in the first schema configured. This defaults to the one of the connection. When you set flyway.setSchemas() it changes it to the first of that list, and uses that one.
In your case this means, with the configuration you have there, Flyway only creates a schema_version table in the db_watson schema.
If you noticed something different, please file an issue with exact steps to reproduce.