I'm using Flyway with Gradle and i need skip some migration files depending the database.
Example:
I have 3 migration files. All of then should be executed in the test database, but has one that shouldn't be executed in the production database.
My question is: Is it possible? If yes, how can i do this?
Thanks
Yes. It is possible. Use different values for flyway.locations based on the environment. Example: http://flywaydb.org/documentation/faq.html#db-specific-sql
Related
I use flyway 8.5.0 and I want that my beforeMigrate or my afterMigrate sql is reported in the history table. Is this feaseable? or is there any config to setup this?
Then an other question: my repetable only runs when they change (checksum) but for my understanding the repetible sql should run every time. not so?
The beforeMigrate and afterMigrate SQL wont appear in your history table. If you look at the tutorial example for callbacks you can see that beforeMigrate can be called before the schema history table is created which would cause issues if it was trying to add itself to it. Additionally, I'm assuming these will be mostly static executions and would not really be part of the version history.
https://flywaydb.org/documentation/tutorials/callbacks
For repeatable, no they are only applied when the checksum has changed.
Repeatable migrations are very useful for managing database objects whose definition can then simply be maintained in a single file in version control. Instead of being run just once, they are (re-)applied every time their checksum changes.
https://flywaydb.org/documentation/tutorials/repeatable
Hello I wanted to ask if, to import the .sql update (after a git pull) I have to assemble and merge with the bash file (app/db_assembler) or if it's ok if I just launch the worldserver.exe and he will do it
Thanks
Short answer
No, the worldserver process will NOT update your database.
You need to use the DB-assembler bash script, as the instructions say.
More details
This is different than in TrinityCore, where it is a feature of the worldserver process to update the database.
In AzerothCore this task is a responsability of an external script, written in bash, the DB-assembler.
The advantage of having an external script to do this task instead of the worldserver is:
You don't need to compile and run the worldserver if you only need to create the database (useful when using or developing tools that only need the DBs)
The DB assembler is able to generate a unique SQL update file per each DB (by merging all the single SQL update files), which can be useful for debugging or development purposes
In general, it is better to delegate different software components for different tasks, instead of having a monolith doing everything
You can also make your own merge script and apply manually. Or just merge with the db_assembler.sh then apply manually.
Else refer to Francesco's answer
I'm evaluating Flyway and want to know if it can check for the presence of any externally made changes? I.e. if someone makes a change directly to the database, outside of Flyway, can I catch that?
I tried validate and info but it doesn't seem to notice.
No, it can't. Flyway expects you to make all changes to what you want it to manage (structure, reference data, ...) via Flyway.
Here at Redgate we support the concept of a schema snapshot. If you use either SQL Server or Oracle (as these are the database we have best support for) then you can take a snapshot after deployment and later compare this artifact with target database the next time you deploy to make sure that it hasn't "drifted". Our tools can also output a candidate Flyway migration script that will ensure Flyway is consistent with the actual target. If you're interested in this approach I can send you sample scripts of how this is achieved. But remember, this only works with Oracle and SQL Server.
I'm wondering if Flyway allows the use a master file to re-enforce the execution orders of procedures, functions, views and triggers in repeatable migrations? Currently I have an in-house tool that generates master files for these objects so that they can be installed without errors (resolves the inter-dependency between them).
Has anyone had similar experience and how did you handle this?
Thanks!
When Flyway finds multiple repeatable migrations that need to run (because they are new or have been modified), Flyway executes them in the alphabetical order of their descriptions.
This should easily allow you to achieve something similar to what your in-house tool did with its master file.
How can I setup a database for testing with my own records when I start executing tests, then work on it, and repeat the process on every action of starting the unit tests?
I mean, where the database should be? Should I create some separate physical database, or add existing test records to it from the code? How can I do that?
Thanks!
There is a separate config file for testing. You can find it as config_test.yml. In this config you can set up a test database which will be used only for testing. So you should use a completely separate database.
The next step is creating some initial data. To do this you can use the DataFixtures bundle.
Further reading: Symfony DataFixtures
Now you have your initial data. The last step is to purge your test databse every time you run a set of tests. I found a pretty good article about it here: Purging your test database in PHPUnit
So I think this is the best practice for functional testing.