We were using a previous 1.7 version of flyway and are trying to upgrade to 2.3. The new flyway seems to not like the format of our migration file names. Is there a way to configure flyway to use a pattern such as this:
00001.US9299.util.util.carete.base.schema.1.sql
00002.US9299.util.util.carete.base.schema.2.sql
00003.Extra.util.add.drop.tables.with.schema.sql
instead of having to rename hundreds of pre-existing migration files to fit the
1_2__Description.sql
pattern?
Flyway 3.0 (due out tomorrow) will let you configure the separator. You can then change the default __ to . to suit your naming convention.
There is however no direct upgrade path from 1.X to 3.0 as the metadata table format changed in 2.X.
Users are advised to do an upgrade to 2.3 first, which will migrate the metadata table automatically, before migrating to 3.0.
In your case that won't work automatically due to the non-standard naming. You will have to convert your metadata table manually as a one-off as part of the upgrade. To help you get started with this, you can take the regular upgrade scripts packaged with Flyway 2.3 as a base.
Related
I made some simple changes on our app that uses EF Core. I just changed the precision of several Decimal typed columns and that is it. When I tried creating a new migration using dotnet ef migrations add ... command, I see migration statements I expect to see:
migrationBuilder.AlterColumn<decimal>(
name: "Value_Amount",
schema: "Payment",
table: "Withdrawals",
type: "DECIMAL(18, 5)",
nullable: false,
oldClrType: typeof(decimal),
oldType: "DECIMAL(15, 2)");
Everything looks good apart that it is also showing tons of weird DropForeignKey, DropUniqueConstraint, DropColumn statements. I went through quite a few of them and none of the columns referenced in the DropX statements even exist in the Database or model classes. The column names in these DropX statements often end in X_TempId, X_TempId1, etc..
I asked my colleague to checkout (using git) the exact same branch as I have and run the exact same commands (using exact same dotnet versions), but his migration is not showing any weird DropXYZ statements. Please correct me if I am wrong, but I believe that dotnet ef migrations add ... command compares the current state from the SomethingModelSnapshot with the latest state in the Model classes and creates DB changes to get from the current state to the latest one. If this is so, running dotnet ef migrations add ... command on the same fileset should always produce the same results, shouldn't it?
Any ideas on what could be happening and/or how to fix this?
Some versions:
dotnet --version = 2.2.100
dotnet ef --version = 2.2.0-rtm-35687
<TargetFramework>netcoreapp2.1</TargetFramework>
Windows 10, commands executed via Powershell.
After some investigation, it seems that this is a bug with EF Core. You can track it here on their github.
This happened after upgrade from 2.1 to 2.2. But note, that this is not a bug of EF Core 2.2 simply, as recreating a new migration from scratch works beautifully on 2.2, but this is more of a breaking change of interpreting model snapshot.
I had the same problem. I'm also using Core 2.2. Was able to get around it by doing a new initial migration. New migrations after that didn't have this problem.
I have installed Flyway in my server and trying to execute a My-sql file which I placed in sql folder of flyway.
I have done Flyway baseline, and when I run flyway migrate it says "Schema xyz is up to date. No migration necessary." No matter what I do it always gives me the same result.
My sql files are named 1__act.sql, 2__act.sql, 3__act.sql.
My config file has
flyway.url=jdbc:mysql://mysql:port/xyz
flyway.user=flywayuser
flyway.password=flywaypassword
flyway.baselineVersion=1
You haven't followed the naming conventions for Versioned SQL migrations, they should be prefixed with a V. e.g. V1__act.sql.
Note that the prefix is configurable, but above is the default.
/src/main/resources/db/migration needs to be a source folder in Eclipse/Spring Tool Suite. Right-click it, Build Path, Use as Source Folder.
Is there any chance I can migrate only one database, if I have define multiple connections in my config.yml
If I run
propel:migration:diff --connection=a it still want to generate migration for all databases defined.
My vendors
propel/propel-bundle 1.2.7 Integration of Propel in Symfony2
propel/propel1 1.6.9 Propel is an open-source Object-Relational Mapping (ORM) for PHP5.
Yes, you can. Although I have Propel 1.7.1 I don't think this has changed since 1.6.9.
You have to create a separate buildtime-conf.xml file for each connection and then pass the path to this file while calling propel-gen diff. So, let's say you have a-buildtime-conf.xml:
propel-gen . diff -Dpropel.buildtime.conf.file=a-buildtime-conf.xml
I found this by debugging the GeneratorConfig::getBuildConnections() method.
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 upgrade an existing rather large application from Symfony 2.0.15 to Symfony 2.4.x (replace with current version).
I'm not quite sure what would be the best strategy to do so. Migration critical features like forms or esi are used, of course :)
Upgrade "step by step" from one major version to another (2.1, 2.2, 2.3, 2.4)
Upgrade directly from 2.0.x to 2.4
Do you have any tips / experience to share ? Would appreciate it :)
Thanks,
Stephan
Each new version comes with an update UPGRADE-2.x.md file containing all intructions to convert your application from the immediately previous version.
I had to do that on my project as well, and I found the step-by-step method more natural and easier to manage. Fact is, there is no file such file as UPGRADE-2.0-to-2.4.md that would help you out for a direct conversion to 2.4.
I shall first recommend to make sure that none of your code uses obsolete functionnalities of Symfony 2.0 (not sure if there are deprecated parts in this version, though), because these can be removed in ulterior versions and will not be included in the UPGRADE file.
If you have done indeep modifications of the core Symfony code, you may find that some undocumented modifications are needed. For instance, there is a custom error handler in my project, extending the Symfony error handler. Well, although it was not documented in the UPGRADE file, the signature of ErrorHandler::handle() was modified and needed to be updated in my custom handler.
Similarly, I had to modify some namespaces because files had been moved in the framework code.
The conversion is still ongoing and I'm currently experiencing a weird error I'm trying to get rid of: The 'request' scope on services registered on custom events generates errors in the logs.