Very Long Oracle View Generate broken java object

10 views
Skip to first unread message

Alessandro Brambilla

unread,
May 7, 2024, 6:26:29 AMMay 7
to jOOQ User Group
Environment:
-JDK21 (but even 17 is KO)
- Oracle DB 19c
- Oracle driver ojdbc11 (23.3.0.23.09) but it happens also with ojdbc10 as well
- Jooq 3.17 (Enterprise)

Hi, 
we have an issue with model generator (by "org.jooq.codegen.GenerationTool" direct call) when generating code for an Oracle View. The whole generated java object looks fine except for one of the private costructor, the one with the TableOptions.view("[ ..... ]") parameter, which contains a string with the whole view's DML Sql code.
At some point of this very long String with DML (the view has something like 600+ fields) the generator put an extra ".toString()" with the wrong escaping like: 

"...... ds.div_espressione_valori AS tcy,\".toString() + "n    NVL(div4.coddiv, '') AS tcy_str,\n  ...."

and then, after another 1k charcter or so, the String is closed, but wronlgy again:

"......... rivalutazione = 1\n".toString() + ""));

Problem is that the bold part make the string illegal (since the "+" is inside " and not outside, so the strings are not concatenated correctly). It looks like there is an extra \" or  a missing one.. one way or another they look not balanced and this brake the code.

We have no idea why this happens, our best guess is that the SQL string is too long, since this string break after more than 16k characters. By the way the view works like a charm in SQL direclty and once we manually fix this issue, also the rest of JOOQ mapping is fine.

Any Idea? are we hitting some hard limit? 

Thank you.

Alessandro

Lukas Eder

unread,
May 8, 2024, 4:21:44 AMMay 8
to jOOQ User Group
Hi Alessandro,

Thanks a lot for your report. This is a funny edge case bug, which I've created here:

The reason for this practice is documented in this earlier bug here:

javac has a size limit for string literals, so we split the literal into several sub literals. We also escape newlines (e.g. \n) and other things, but unfortunately, that is being done before the splitting, so it is (rarely) possible for the splitting to happen exactly where the escaped newline is located, thus separating "\" from "n", which is obviously wrong.

I'll fix #16662 right away. As a workaround, you can:

- Insert arbitrary characters (e.g. whitespace) into your view source code to avoid the issue for this particular view
- Post-process generated code to fix this issue

I hope this helps,
Lukas

Alessandro Brambilla

unread,
May 8, 2024, 6:57:39 AMMay 8
to jOOQ User Group
Thank you Lukas, 
nice and deep explanation! And very fast bugfixg ;) 
We will go for not generating the SQL since we don't really need it. 

Have a nice day.

Alessandro

Reply all
Reply to author
Forward
0 new messages