Digest for jooq-user@googlegroups.com - 2 updates in 1 topic

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Digest for jooq-user@googlegroups.com - 2 updates in 1 topic

http://groups.google.com/group/jooq-user/topics mailing list
[hidden email]: Nov 07 11:13PM -0800

I have a derby embedded database that was created with the following URL
The collation value is set to allow case-insensitive matching for queries
that use the sql LIKE keyword.
Now I'm trying to generate jOOQ files for it, and I'm getting the following
error message:
Comparisons between 'VARCHAR (UCS_BASIC)' and 'VARCHAR
(TERRITORY_BASED:PRIMARY)' are not supported. Types must be comparable.
String types must also have matching collation. If collation does not
match, a possible solution is to cast operands to force them to the default
collation (e.g. SELECT tablename FROM sys.systables WHERE CAST(tablename AS
VARCHAR(128)) = 'T1')
Does anyone know how to get around this?
I should say that I removed the <inputSchema>mySchema</inputSchema> tag
from the library file since it generated a different error that said this: No
schemata were loaded : Please check your connection settings, and whether
your database (and your database version!) is really supported by jOOQ.
Here's my library.xml file:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<configuration xmlns="http://www.jooq.org/xsd/jooq-codegen-3.10.0.xsd">
<!-- Configure the database connection here -->
<!--user and password are presumably not needed since we're embedded.-->

<!--I tried it both with and without these properties, which, frankly were a guess.
It failed both ways with the same message.-->
<!-- The database schema (or in the absence of schema support, in your RDBMS this
can be the owner, user, database name) to be generated -->
<!-- The destination package of your generated classes (within the destination directory) -->
<!-- The destination directory of your generated classes. Using Maven directory layout here -->
Lukas Eder <[hidden email]>: Nov 08 09:34AM +0100

For future reference, this issue was also reported here on GitHub:
I'm generally wary of setting the collation to something non-default on a
connection / database level. I've only ever found this feature useful on an
individual column level. In principle, 'A' != 'a' for most purposes (e.g.
comparing two hashes), and only in some very few cases, I'd like this sort
of case insensitive behaviour to work automatically, and even then, I
generally prefer a programmatic workaround (e.g. creating a function based
index on UPPER(column) or some other normalisation function, if UPPER()
doesn't behave correctly in all languages).
I'm not sure about a workaround here - have you considered asking this
question on Stack Overflow (and perhaps reducing your API usage to JDBC
only, to get more people to look into this)?
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to [hidden email].