Skip to content
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

DB2Parser struggles with block depth count #2379

wallenborn opened this issue May 8, 2019 · 6 comments

DB2Parser struggles with block depth count #2379

wallenborn opened this issue May 8, 2019 · 6 comments


Copy link

@wallenborn wallenborn commented May 8, 2019

Which version and edition of Flyway are you using?

Cloned from git, most recent commit is

If this is not the latest version, can you reproduce the issue with the latest one as well?

(Many bugs are fixed in newer releases and upgrading will often resolve the issue)

Which client are you using? (Command-line, Java API, Maven plugin, Gradle plugin)


Which database are you using (type & version)?

DB2/LINUXX8664 10.5.5

Which operating system are you using?

Windows 10/cygwin

What did you do?

(Please include the content causing the issue, any relevant configuration settings, the SQL statement that failed (if relevant) and the command you ran.)

After upgrade to the current version i ran a
flyway -configFiles=/path/to/flyway-TEST.conf -locations=filesystem:TEST info
on a database that was setup with an earlier version of flyway

What did you expect to see?

The usual migration list with status success for the migrations applied before

What did you see instead?

Flyway Community Edition 5.2.3 by Boxfuse
Database: jdbc:db2://localhost:50000/test (DB2/LINUXX8664 10.5)
ERROR: Unable to parse statement in TEST\R__0.0.1_foo.sql at line 2 col 1: Flyway parsing bug: unable to decrease block depth below 0

Rerunning the command with the -X flag produced the following stacktrace:

org.flywaydb.core.api.FlywayException: Unable to parse statement in TEST\R__0.0.1_foo.sql at line 2 col 1: Flyway parsing bug: unable to decrease block depth below 0
at org.flywaydb.core.internal.parser.Parser.getNextStatement(
at org.flywaydb.core.internal.parser.Parser.access$000(
at org.flywaydb.core.internal.parser.Parser$ParserSqlStatementIterator.(
at org.flywaydb.core.internal.parser.Parser.parse(
at org.flywaydb.core.internal.sqlscript.ParserSqlScript.(
at org.flywaydb.core.internal.database.db2.DB2Database.createSqlScript(
at org.flywaydb.core.internal.resolver.sql.SqlMigrationResolver.addMigrations(
at org.flywaydb.core.internal.resolver.sql.SqlMigrationResolver.resolveMigrations(
at org.flywaydb.core.internal.resolver.sql.SqlMigrationResolver.resolveMigrations(
at org.flywaydb.core.internal.resolver.CompositeMigrationResolver.collectMigrations(
at org.flywaydb.core.internal.resolver.CompositeMigrationResolver.doFindAvailableMigrations(
at org.flywaydb.core.internal.resolver.CompositeMigrationResolver.resolveMigrations(
at org.flywaydb.core.internal.resolver.CompositeMigrationResolver.resolveMigrations(
at org.flywaydb.core.Flyway$4.execute(
at org.flywaydb.core.Flyway$4.execute(
at org.flywaydb.core.Flyway.execute(
at org.flywaydb.commandline.Main.executeOperation(
at org.flywaydb.commandline.Main.main(
Caused by: org.flywaydb.core.api.FlywayException: Flyway parsing bug: unable to decrease block depth below 0
at org.flywaydb.core.internal.parser.ParserContext.decreaseBlockDepth(
at org.flywaydb.core.internal.database.db2.DB2Parser.adjustBlockDepth(
at org.flywaydb.core.internal.parser.Parser.getNextStatement(
... 20 more

The migration in question is a stored procedure definition, one of many. Previous migrations with other stored procedures went through without a problem. One difference between the migration is that this one contains a construct like this:

        CASE S.IS_X
            WHEN 1 THEN S.CODE
            ELSE NULL END,
        CASE S.IS_Y
            WHEN 1 THEN S.CODE
            ELSE NULL END

In the source i see that DB2Parser increases the block depth counter on

"CASE".equals(token.getText()) && !"END".equals(previousToken.getText())

Wouldn't this break in the case above when a CASE is immediately preceeded by the END of the previous clause?

Copy link

@axelfontaine axelfontaine commented May 8, 2019

Please try again with 6.0.0-beta. The parser was rewritten from the ground up and this change eliminated entire classes of errors. Did this fix the issue?

Copy link

@wallenborn wallenborn commented May 8, 2019

Copy link

@axelfontaine axelfontaine commented May 8, 2019

We just tested this internally and this statement parses correctly with the latest code.

Copy link

@axelfontaine axelfontaine commented May 10, 2019

Reopening as we now have managed to reproduce this.

axelfontaine pushed a commit to flyway/ that referenced this issue May 10, 2019
Copy link

@wallenborn wallenborn commented May 14, 2019

@axelfontaine axelfontaine removed this from the Flyway 6.0.0 milestone May 22, 2019
@axelfontaine axelfontaine added this to the Flyway 6.0.0-beta2 milestone May 22, 2019
dohrayme pushed a commit to dohrayme/flyway that referenced this issue Feb 3, 2020
Copy link

@FilenkovMaxim FilenkovMaxim commented Feb 11, 2020

I had this bug on 6.0.1 version
The report from crashlitycs:

Non-fatal Exception: org.flywaydb.core.api.FlywayException
Unable to parse statement in db/migration/V1.2__triggers.sql at line 30 col 1: Flyway parsing bug: unable to decrease block depth below 0
org.flywaydb.core.internal.parser.Parser.getNextStatement (
org.flywaydb.core.internal.parser.Parser.access$000 (
org.flywaydb.core.internal.parser.Parser$ (
org.flywaydb.core.internal.parser.Parser$ (
org.flywaydb.core.internal.sqlscript.ParserSqlScript.parse (
org.flywaydb.core.internal.sqlscript.ParserSqlScript.validate (
org.flywaydb.core.internal.sqlscript.ParserSqlScript.executeInTransaction (
org.flywaydb.core.internal.resolver.sql.SqlMigrationExecutor.canExecuteInTransaction (
org.flywaydb.core.internal.command.DbMigrate.isExecuteGroupInTransaction (
org.flywaydb.core.internal.command.DbMigrate.applyMigrations (
org.flywaydb.core.internal.command.DbMigrate.migrateGroup (
org.flywaydb.core.internal.command.DbMigrate.access$100 (
org.flywaydb.core.internal.command.DbMigrate$ (
org.flywaydb.core.internal.command.DbMigrate$ (
org.flywaydb.core.internal.database.base.Connection$ (
org.flywaydb.core.internal.jdbc.TransactionTemplate.execute (
org.flywaydb.core.internal.database.base.Connection.lock (
org.flywaydb.core.internal.schemahistory.JdbcTableSchemaHistory.lock (
org.flywaydb.core.internal.command.DbMigrate.migrateAll (
org.flywaydb.core.internal.command.DbMigrate.migrate (
org.flywaydb.core.Flyway$1.execute (
org.flywaydb.core.Flyway$1.execute (
org.flywaydb.core.Flyway.execute (
org.flywaydb.core.Flyway.migrate (
database.Database.migrate (

The device was Samsung Galaxy J5, Android 9

It cannot parse this:

CREATE TRIGGER product_type_mobile_uatr
after update of price
on product_type_mobile_t
for each row
-- when old.update_f = 0
select case
when new.product_type_id != old.product_type_id
then raise(abort, 'No change product_type_mobile_t(product_type_id)!')
when !=
then raise(abort, 'No change product_type_mobile_t(id)!')
end/* comment for fix parser bug */;
update product_type_mobile_t
set update_f = 1,
update_dt = strftime('%Y-%m-%dT%H:%M:%S', 'now', 'localtime'),
u_dt = strftime('%Y-%m-%dT%H:%M:%f', 'now', 'localtime'),
u_user_cd = (select v.var_value
from app_var_t v
where v.var_name = 'SESSION_CODE'
where id =;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants