migrations
migrations copied to clipboard
mybatis
Use native DELIMITER
following on #88 mybatis should honor native DB delimiters in order to support stored procedures and such.
Benefits to this approach
- In the unlikely event that a migration goes wrong the original SQL script can be run with the native client
- Reduces the friction to adoption by those familiar with the native tooling due to 1)
- use of
migrate scriptmay generate a script that is intended to be run with a native client. However, without the native delimiter this would not be possible.
Since all DBs potentially (likely) use different delimiters, basically either a simple Map<String,Consumer<String>> need be implemented where the key is the command word to check to see if it's a delimiter word and the consumer is what should be done with the word to correctly process it. This follows the Command Pattern
a sketched implementation:
Map<String,Consumer<String>> COMMANDS = new HashMap<>();
COMMANDS.put("DELIMITER", c -> this.delimiter = c); // mysql version
COMMANDS.put("CHANGE", c -> this.delimiter = c.split(" ")[1]); // ORACLE version CHANGE / %
Consumer<String> whatToDo = COMMANDS.getOrDefault(command,c -> sendToDb(c));
whatToDo.accept(command);
An alternative implementation might require deeper logical inspection with the application of a series of predicates. Hopefully that's not necessary
Both of your ideas require to implement database dependent patterns (dialects) in Migrations code and we do not do that.
Instead, I plan to add a new option delimiter_prefix or delimiter_pattern.
This will work with any database without modifying Migrations code.
In your case, the configuration will look like...
delimiter_prefix=DELIMITER
This meets your requirement, doesn't it?
My case? Sure. The general case? No. For oracle, the syntax is
SET CMDS[EP] {; | c | ON | OFF}
example:
SET CMDSEP ON
SET CMDSEP "!"
SHOW CMDSEP! SHOW BUFFER!
So, while it won't be easy (hence the suggestion of using predicates and an AbstractFactory) what you have won't work.
Hi @chb0github ,
Sorry for a late reply. At this point, I am not sure if there is a universal solution that does not involve dialect or similar. Please use hooks for now.
How about we leave the issue open as a feature request? Closing an issue means it's not an issue any more and becomes less visible.
And, as I suggested: A dialectic approach is the right approach but is definitely involved