You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the Sql split logic used throughout liquibase splits on delimiters. That works fine, as long as the delimiter characters are not used inside statements.
The main time when delimiters can be in statements are in stored procedures such as:
CREATE PROCEDURE country_hos(IN con CHAR(20))
BEGIN
SELECT Name, HeadOfState FROM Country
WHERE Continent = con;
END
were the ; after WHERE Continent = con makes liquibase split that one statement into two.
This causes the SQL to fail with unexpected end of statement type errors.
Change
Most databases use a BEGIN / END keyword pair to delimit the points where we should ignore delimiters, so we should add logic to check for those tokens and NOT split on the delimiters inside them. This will make the SQL parsing significantly smarter.
A common split function is used anywhere we are splitting sql:
In formatted sql by default
In tags with splitStatements=true
In the executeSql command
Requirements
Formatted SQL plus and based SQL with splitStatements=true now correctly run stored procedure, function, trigger, etc. definitions with ;'s in the middle of it correctly as long as the statement uses BEGIN/END syntax. Even without changing the endDelimiter setting.
Environment
Liquibase Version: 4.2.0
Liquibase Integration & Version: All
Description
Currently the Sql split logic used throughout liquibase splits on delimiters. That works fine, as long as the delimiter characters are not used inside statements.
The main time when delimiters can be in statements are in stored procedures such as:
were the ; after
WHERE Continent = con
makes liquibase split that one statement into two.This causes the SQL to fail with
unexpected end of statement
type errors.Change
Most databases use a BEGIN / END keyword pair to delimit the points where we should ignore delimiters, so we should add logic to check for those tokens and NOT split on the delimiters inside them. This will make the SQL parsing significantly smarter.
A common split function is used anywhere we are splitting sql:
Requirements
splitStatements=true
now correctly run stored procedure, function, trigger, etc. definitions with ;'s in the middle of it correctly as long as the statement uses BEGIN/END syntax. Even without changing the endDelimiter setting.┆Issue is synchronized with this Jira Bug by Unito
The text was updated successfully, but these errors were encountered: