Open O1O1O1O opened 6 years ago
See https://github.com/JSQLParser/JSqlParser/issues/698
This is most frustrating... will your work on https://github.com/olavloite/spanner-jdbc/pull/127 have any impact on this or does all source still have to go through the problematic JSQLParser ?
@O1O1O1O I am planning to replace the JSQLParser with my own simple parser for most SQL statements once #127 is done.
@O1O1O1O I have created a quick fix for this problem and released a 1.1.4 version for queries that do not contain any JDBC parameters. These do not need to be parsed by the SQL parser and can be sent directly to Spanner, so these error will be ignored for those queries. Queries that do contain parameters, however, will still rely on the SQL Parser for processing and will fail in version 1.1.x.
The issue will therefore remain open for a better fix in 1.2 where these queries will not rely on the SQL Parser for parameter processing.
Thanks for the quick workaround Knut. Does the entire query have to be unparameterized, or do you mean it is only a problem if the array index is itself unparameterized?
Unfortunately since I'm on a tight deadline I had to switch to the Simba driver which I just noticed now supports full DML (and the Spanner console is now upgraded to support it too). It is not without issues - you can't write Long to an INT64 column.
I had to revert to using your driver as the Simba driver was not compatible with connection pools in Scala Play (all kinds of multi-threading corruption issues occurred). So I was able to test your fix for this and everything is working fine. It was not a big issue that I could not use prepared statements with parameters since the only parameter I really needed to insert was an integer. Thanks for the quick fix. Looking forward to trying 1.2
When attempting to access an item of an array in a query using syntax that is accepted in interactive SQL console we get a parsing error from
nl.topicus.jdbc.shaded.net.sf.jsqlparser