I want to use flyway for an existing application.
There should be two different cases:
1) Application installation: DDL and initilization of the Database
2) Application update: migrate database
The problem is if i install Version 6.0 i have e.g.:
V1_0_1__CreateShema (for 6.0.0)
V1_0_2__InitData (for 6.0.0)
....
V4_0_0__Update_DDL_and_DML
V5_0_0__Update_DDL_and_DML
V6_0_0__Update_DDL_and_DML
If i set init version to V1.0.0 it will execute all updates until V6_0_0 but it should skip all updates after initialization of the Database.
To install an old shema so i can use all udpate scripts even for a fresh install would be very hard (no db version history so i have to do reverse engineering)
I could use a workaround:
1) Check if version table exist
2) If not - migrate to version 1.0.2
3) drop the version table
4) init again with version 6.0.0
There should be a better way isnt it?
I've highlighted the problem:
V1_0_1__CreateShema (for 6.0.0)
V1_0_2__InitData (for 6.0.0)
To get to 6.0 you should run all scripts up to V6_0_0__Update_DDL_and_DML
V1 should be for V1 and never change afterwards.
Related
Is there a Linux equivalent of LightIngest.exe? The page of the utility does not mention that, search brings no luck either. In case it is not available, what is the preferred way to post ingestion items through CLI in Linux?
There is a .NET Core Kusto.Tools package - it is currently built for Core 2.1 and we will be working on updating it in the coming weeks.
https://www.nuget.org/packages/Microsoft.Azure.Kusto.Tools.NETCore/
Thanks to Vladik's answer I was able to download the package and use the included LightIngest.dll to execute an ingest through my Mac. Here are the steps:
Use nuget to download the Microsoft.Azure.Kusto.Tools.NETCore package installed:
nuget install Microsoft.Azure.Kusto.Tools.NETCore -Source nuget.org -OutputDirectory SPECIFY_OUTPUT_DIRECTORY
Navigate to the directory, and go to the tools subfolder. There you should find LightIngest.dll
Assuming you have dotnet installed (CLI) and SDK (v2.1) you should be able to execute an ingestion:
dotnet ./LightIngest.dll ...
Replace the ... with the Windows equivalent command that Azure Data Explorer Ingestion wizard suggested, and it should start ingesting!
I am currently working to get Flyway 3.0 version up to 4.2.0 and am having some trouble going from 3.0 -> 4.2.0. So far I've pulled in the 4.2.0 dependency and updated the renamed config fields.
When looking through the Flyway migration docs & issues it seemed that when a user runs flyway on version 4.2.0 that the checksums update automatically. I assumed that meant flyway migrate or any relevant commands would trigger this update, via the documentation:
Flyway 4.0 now ignores line endings when calculating checksums and all existing checksums in your metadata table will be automatically adjusted on first run to be compatible with this new algorithm.
However, the checksums did not update when running flyway migrate. As a work around, I found the helpful repair command which amends the migration checksum values from the old version to the new version and ran that:
flyway repair -user=user -password=password -url=jdbc:mysql://127.0.0.1:3306/db -table=db_migrations
Flyway 4.2.0 by Boxfuse
Database: jdbc:mysql://127.0.0.1:3306/db_migrations (MySQL 5.6)
Repair of failed migration in metadata table `db_migrations`.`schema_version` not necessary. No failed migration detected.
Successfully repaired metadata table `db_migrations`.`schema_version` (execution time 00:00.005s).
Manual cleanup of the remaining effects the failed migration may still be required.
Database: jdbc:mysql://127.0.0.1:3306/db_migrations (MySQL 5.6)
Repair of failed migration in metadata table `db_migrations`.`schema_version` not necessary. No failed migration detected.
Successfully repaired metadata table `db_migrations`.`schema_version` (execution time 00:00.004s).
Manual cleanup of the remaining effects the failed migration may still be required.
[1]- Done flyway repair -user=user -password=password -url=jdbc:mysql://127.0.0.1:3306/db -table=db_migrations
[2]+ Done flyway repair -user=user -password=password -url=jdbc:mysql://127.0.0.1:3306/db -table=db_migrations
The checksums updated but when I ran flyway info it shows that all the previous migrations are now marked future. Looking through the documentation future is defined:
These are migrations that were performed by a newer deployment of the application that are not yet available in this version. For example: we have migrations available on the classpath up to version 3.0. The schema history table indicates that a migration to version 4.0 (unknown to us) has already been applied.
However when checking the version I get the correct one:
flyway -v
Flyway 4.2.0 by Boxfuse
TLDR: Ran the repair command to update migration checksums and now flyway tells me the migrations have a checksum from a future version. Checked command line flyway and application flyway version and they are both at 4.2.0. Unsure how to debug / proceed. Any help would be appreciated.
Edit: Found one of the maintainers comments on another question defining future further
future -> executed, no longer found in configured locations, newer than the newest found script
So possibly the cmd line flyway can't locate the migration scripts it sees in the db?
Is there any possibility to migrate database changes to any specific version. As a example we have list of migration within out project and we want to migrate only version 2 changes into the database. I may have below migrations
Version 1 - Already in DB
Version 2 - Want to migrate to the DB
Version 3 - Will migrate later.
Is there any command like migrate:up --Version 2? I am using FluentMigrator.1.4.0.0
I manage to do this using below script.
Migrate.exe /connection "data source=source;initial catalog=db;User ID=sa;Password=123;" /db SQLserver2012 /timeout 600 /task migrate:up --version=2 /target ..\DatabaseMigration\bin\Debug\DatabaseMigration.dll
pause
I'm trying to host a meteor app that uses an old version of meteor.
Every time i try to start the app it will get somewhat through the process of installing the tool, and then i see a message such as:
Killednloading meteor-tool#1.1.3... -
(note how killed somehow overwrites the downloading part of the command line)
Is there a reliable way to install the meteor tool at a specific version?
EDIT:
The Meteor team added a release parameter to their download endpoint. Now you can simply specify the desired version:
curl "https://install.meteor.com/?release=1.3.3.1" | sh
For Windows, a version parameter exists for the choco installer:
choco install meteor --version 1.3.3.1
Original solution
You can use sed for that. Insert it in the middle of curl and sh:
curl https://install.meteor.com/ | sed 's/1.4/1.3.3.1/' | sh
That will replace the release 1.4 (current version) to 1.3.3.1
When you create a meteor app you can specify a release:
meteor create test --release x.y.z
And when you update a meteor app you can do the same:
meteor update --release x.y.z
#Jorge Issa's answer is good if you are installing Meteor from scratch, on a system that never had Meteor installed, however it's subject to change since versions change all the time, so you need to adapt the sed line.
If you have any version of Meteor already installed, as Michel Floyd mentioned, you can always create a project with a specific version by adding the --release flag.
meteor update --release xxxx works fine with you're actually upgrading, but downgrading is a different story.
My recommendation when it comes to upgrading and eventually downgrading, is to use version control (git).
Attempt upgrade and if all is fine, you're in good shape, if not and you want to downgrade, simply clear the file changes in your version control system and use meteor reset to clean your project and rebuild with the previous version.
!Note! meteor reset clears the local mongo database too, so be sure to back that up first if you're going to do that (check mongodump and mongorestore for that)
finally, if you're looking to clean up the clutter from the .meteor folder, you can delete the folder and then run meteor reset in your project: the meteor executable will detect you don't have the needed packages will re-download the packages for the version needed by your project. (This takes a while and if you have many project, can be cumbersome as you need to do this in each project, but if like me you are looking to clear some space, this works fine.)
Try:
meteor update --release x.y.z
Try
choco install meteor --x86 --params="'/RELEASE:1.5.4.4'"
Is there a way to bypass the auto update feature of Meteor?
I'm stuck with
Downloading meteor-tool#1.3.0_3... \
When I try to run existing project, or create a new one or simply run "meteor list",..It starts updating, downloads meteor-tool#1.3.0_3... which completes 100% and then countdown vanishes & it remains like that with the spindle rotating.
I tried waiting like mentioned at this link
However, nothing happens even after an hour.
I've same error. I resolve by following steps, please try
Download meteor installation from https://github.com/meteor/meteor/wiki/Meteor-on-Windows:-Alternate-installation
Extract zip & Copy all tool from .meteor/packages/meteor-tool directory
Go To %AppData%/../Local/.meteor/packages/meteor-tool or C:\Users\<your_user_name>\AppData\Local\.meteor\packages\meteor-tool
Paste inside folder (Note: If you can't copy or gives error of long path, use RoboCopy)
Now, you can create new Meteor app.
Go to project > .meteor > release
Change the meteor version to the current one that is installed on your system.
Consider my scenario:
1) System have the Meteor version 1.4.3.1 installed
2) Downloaded the todos(meteor project), developed on version 1.4.2.1
3) On running it gives similar problem
4) Changed the release version to 1.4.3.1
5) Run with command 'meteor'
Considering latest Meteor 1.6 you can use below commands for your best needs
meteor create . --release 1.5 --full to create a scaffolded app.
meteor create . --release 1.5 --bare to create an empty app.
NOTE: Instead of --release 1.5 you could use your version which actually exists.