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

Incorrect parsing when space is missing between end quote and next token #921

Closed
cosmin opened this issue Jan 9, 2015 · 3 comments
Closed

Comments

@cosmin
Copy link

cosmin commented Jan 9, 2015

I noticed some odd errors where Flyway was failing to parse our SQL migrations properly, and ended up concatenating 30,000 lines of SQL together into a single procedure. I traced this down to a bug with parsing string tokens, as evidenced by the following script that should parse as 2 sql statements

CREATE OR REPLACE PROCEDURE FOOBAR
(
    FOO IN OUT VARCHAR2,
    BAR  IN OUT VARCHAR2
)
AS

BEGIN
    IF FOO = 'FOO'THEN
        BAR := 'BAR';
    END IF;
END;
/

CREATE OR REPLACE PROCEDURE BARBAZ
    (
        BAR  IN OUT VARCHAR2,
        BAZ  IN OUT VARCHAR2
    )
AS

BEGIN
    IF BAR = 'BAR'THEN
        BAZ := 'BAZ';
    END IF;
END;
/

Notice the lack of a space between the ' and the subsequent THEN. This causes Flyway to think it is still inside of a quoted string literal and therefore it continues to parse all of the rest of the file as being part of the current statement.

I can obviously rewrite the original SQL, but it would be nice to fix the tokenizer to work properly. Every other tool I use parses this statement properly, including IntelliJ, SQL Developer, sqlplus, etc. Having a sql statement work properly in the developer tool, but fail in exciting way when run as part of a migration is obviously not a great behavior.

@cosmin
Copy link
Author

cosmin commented Jan 9, 2015

This can also happen when the opening quote does not have a white space before the preceding character, for example in the following block

IF'FOO' = 'FOO' THEN
    BAR := 'BAR';
END IF;

@axelfontaine
Copy link
Contributor

Yes, there is indeed no support yet for this Oracle-specific oddity (as described in the known limitations: http://flywaydb.org/documentation/database/oracle.html)

@axelfontaine axelfontaine added this to the Flyway 3.2 milestone Jan 10, 2015
axelfontaine pushed a commit to flyway/flywaydb.org that referenced this issue Jan 10, 2015
@axelfontaine
Copy link
Contributor

Should be fixed now. Please try again with your 30000 line file to make sure no edge case was missed.

Cheers,
Axel

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

No branches or pull requests

2 participants