added support for non-transactional SQL migrations #1027
Conversation
- added new Resolver and Executor classes - NTSqlMigrationResolver works on the files prefixed with "NTV", currently hardcoded - added small test for new resolver
|
+1 for this feature. |
|
+1 |
4 similar comments
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
when will this feature be merged into flyway? |
|
For anybody that is looking for a quick and dirty way to mix in some non-transactional migrations into an existing SQL-based patch series, I knocked out the following shim: public abstract class AbstractResolvedMigration implements ResolvedMigration {
private final String version;
private final String description;
public AbstractResolvedMigration() {
String className = this.getClass().getSimpleName();
String template = "V(\\d+)__(.*)";
Pattern pattern = Pattern.compile(template);
Matcher matcher = pattern.matcher(className);
if (matcher.matches()) {
this.version = matcher.group(1);
this.description = matcher.group(2).replaceAll("_", " ");
} else {
throw new RuntimeException("Bogus migration name: " + className);
}
}
@Override
public MigrationVersion getVersion() {
return MigrationVersion.fromVersion(version);
}
@Override
public String getDescription() {
return description;
}
@Override
public Integer getChecksum() {
final CRC32 crc32 = new CRC32();
crc32.update(getScript().getBytes());
return (int) crc32.getValue();
}
@Override
public MigrationType getType() {
return MigrationType.CUSTOM;
}
@Override
public String getPhysicalLocation() {
return "virtual://loaction";
}
@Override
public MigrationExecutor getExecutor() {
return new MigrationExecutor() {
@Override
public void execute(Connection connection) {
PreparedStatement stmt;
try {
stmt = connection.prepareStatement(getScript());
stmt.execute();
} catch (SQLException e) {
throw new RuntimeException(e);
}
}
@Override
public boolean executeInTransaction() {
return false;
}
};
}
}And then if I need to execute something outside of a TX, I subclass the base class to supply the patch specific SQL. For example, say I have a V50 SQL migration that requires a new type in Postgres, I create a V49 custom migration that patches the DDL in a non-TX migration in order that the subsequent V50 migration that depends on the new type can execute: public class V49__some_meaningful_description extends AbstractResolvedMigration {
@Override
public String getScript() {
return "ALTER TYPE foo ADD VALUE 'BAR' AFTER 'BAZ';";
}
}And then to mix the V49 migration into the execution series, you need to add a bit of resolver glue and then tell Flyway about it at runtime: public class NonTransactionalMigrationResolver implements MigrationResolver {
@Override
public List<ResolvedMigration> resolveMigrations() {
List<ResolvedMigration> resolvedMigrations = new ArrayList<>();
resolvedMigrations.add(new V49__some_meaningful_description());
// add any other non-TX migrations to this list
return resolvedMigrations;
}
}Hope this can help somebody until such a time that there is a less hacky way to do this kind of thing. |
|
+1 |
|
+1 @axelfontaine Is there anything we can do to help get this PR in shape to be merged? |
|
+1 |
5 similar comments
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
When would this feature be merged into master? We have currently issues too, where we need migrations to run in an non transactional context. |
|
+1 |
1 similar comment
|
+1 |
|
any updates for this issue? |
|
+1 |
|
@axelfontaine dies this change has a Chance of being merged? |
|
+1 |
|
@axelfontaine Would you consider merging this PR? |
|
I wouldn't want non-transactional migrations to have a different runtime order than the regular V1_Description.sql files. I would prefer something like V53_NT__Description.sql or V53__NT_Description.sql so they would run in line with other transactional migrations. |
|
@Trekoid this patch does maintain the order. V1_foo.sql, NTV2_bar.sql and V3_baz.sql files will get executed in foo, bar, baz order. On the other note, this PR is vastly out of date, there are hundreds of commits in between and this will probably require work from scratch. |
|
Hey @Omie, Just to add to @Trekoid's comment: My IDE orders files alphanumerically and having it named Just my 2 cents. Awesome PR BTW. I'd love to see this finally get merged soon. |
|
@davidvuong your should be happy to hear the company I work for co-sponsored the development of non-transactional migrations with BoxFuse, so expect it soon in release 4.1. The solution @axelfontaine and the team at BoxFuse created requires no special file naming. It will auto detect the migration and run it appropriately. |
|
@Trekoid That's awesome. Looking forward to it! |
|
Hey, I've also worked on a non transactional resolver for flyway. It scans for sql files with suffix .ntx.sql and executes them in a nontransactional context. It works only with flyway maven plugin... so you can add it as a dependency in maven pom and add the custom resolver in the flyway-maven-plugin. if anyone is interested, i'll put it on gitlab and maven central. |
|
Anything? |
|
This has been implemented differently using auto-detection (PostgreSQL only for now). Closing. |
|
@andrewlmurray Pls help org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'flywayInitializer' defined in class path resource [org/springframework/boot/autoconfigure/flyway/FlywayAutoConfiguration$FlywayConfiguration.class]: Invocation of init method failed; nested exception is org.flywaydb.core.api.FlywayException: Unable to parse statement in db/migration/V1_1__Identity_Service_dml.sql at line 1 col 1: No value provided for placeholder: ${USER_NAME}. Check your configuration! |
20 participants
fixes #1026