Original author: ospy...@gmail.com (September 25, 2012 10:36:53)
and thanks a lot for the effort you put in flyway. We are currently searching for a solution as close as possible to the way we work:
DDL code is maintained in a number of files categorized mostly by type e.g. Tables.sql, Views.sql, while procedural code is kept in a Packages directory with one file per package e.g. Package1.sql, Package2.sql etc.
For Tables and Views changes are appended at the bottom of each file (starting with a comment with the issue number). Example Tables.sql:
For us this is a very convenient setup, allowing to apply migrations after a specific issue - revision by opening a minimal set of files and copying from the desired line to the bottom of the file (or using the file as is for packages).
Is this a use case excluded from flyway initial design for some reason? Do you think it could be included at some point in the future?
Thanks again, hope the above makes some sense!
Original issue: http://code.google.com/p/flyway/issues/detail?id=336
The text was updated successfully, but these errors were encountered:
From firstname.lastname@example.org on October 05, 2012 13:12:27
I see where you are coming from. This type of deployment where a lot of logic resides in the DB is indeed no optimally supported at this time.
A workaround could be to have a separate Flyway instance, with its own metadata table, managing only the packages. You could then piggyback on the clean on validation error functionality to edit the files in place and then, using the change in checksum to trigger Flyway to redeploy them.
From dyo...@gmail.com on January 31, 2013 02:08:04
1, flyway.sh info
Did I miss anything on the Clean on Validation feature?
From email@example.com on January 31, 2013 07:37:43
Example from the website for use in a properties file: flyway.cleanOnValidationError=true
From dyo...@gmail.com on January 31, 2013 20:11:11
In the properties file,
Output from running flyway.sh,
Validated 3 migrations (execution time 00:00.045s)
Current schema version: 2
From dyo...@gmail.com on January 31, 2013 23:32:53
Looks like one invalid object causes the entire schema to be wiped out. That's a huge risk. I'll have to keep that property out of our production environment.
Ability to migrate Oracle package/procedure/function is the top feature we'd like to have, since they account for the majority of our database objects. Do you plan to add that feature in a future release?
…cle only for now)