-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do not split SQL on delimiters within BEGIN/END blocks #1589
Conversation
- Handle nested begin/end statements LB-958
@nvoxland Thanks for making the updates for nested BEGIN END statements. At least one more use case to consider that I missed earlier. What about BEGIN TRANS or BEGIN TRANSACTION statements? |
Good point on |
@nvoxland, thank you for this improvement! Stored logic delimiters are one of the most frustrating bits of changeset configuration to get right. I think this will be helpful. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Enhancement improves handling of stored logic SQL that contains internally-delimited statements wrapped in BEGIN...END.
- Liquibase no longer attempts to parse the statements within BEGIN...END keywords using the endDelimiter defined on the changeset. Statements with in BEGIN...END are taken as is for execution against the database.
- New unit tests added to validate several BEGIN...END parsing use cases.
- No additional testing required.
APPROVED
@nvoxland Do we have docs that need to be updated/improved with this change? Thanks! |
This created a regression for files containing begin and commit . Those now fail as their statements are not properly separated anymore. And unfortunately the way this was implemented it is not possible to know the closing statement for a begin statement, to only apply for begin-end and not other closing statements. |
Description
Currently we apply the endDelimiter logic in parsing sql throughout the SQL. But stored logic, views, and other SQL will often have otherwise-delimiters inside their "body" which is delineated with BEGIN/END statements.
This updates the parsing logic to not look for delimiters while inside a BEGIN/END statement, thereby removing a lot of the need to specify "endDelimiter" in the first place.
NOTE: It will not count
BEGIN/END TRANSACTION
blocks as "begin/end" blocksFixes LB-958
Fixes #1553
Things to be aware of:
Things to worry about: