It turns out that this issue was rather easy to fix. This SQLDialectNotSupportedException shouldn't be thrown from the mostSpecific() method: https://github.com/jOOQ/jOOQ/commit/24254e039e5e9d0e69af2146e9953defa3df4db5
Unfortunately, I had released jOOQ 2.6.3 today, so this fix will have to wait for 2.6.4 to be published. > Is there a missing case here? Basically, I see this as a difference of an > unresolved type vs the type OTHER (which is specifically unspecified - > hahah). > > Maybe you really need to have something like: > > SQLDataType.USERDEFINED > SQLDataType.UNRESOLVED > > Instead of overloading SQLDataType.OTHER. What would be the added value of these types? To me, java.sql.Types.OTHER is the most appropriate JDBC type for what you call unresolved / userdefined: http://docs.oracle.com/javase/7/docs/api/java/sql/Types.html#OTHER > The NPE was coming out of my trying to use create.insertInto query parts > instead of a Record.store() call. Basically, I have to cast the > pgo.toString() result to a type in the query right now, and the code is > super bad. > > So its critical that I be able to pass the PGobject through to JDBC, > unmolested by jOOQ - to put it bluntly. Yes, I got that now. You can stop instisting :-) The NPE is a bug, which was easy to fix even before introducing formal PG* support... > Is there any way to get the statement a store would make, or approximate it? > I'll go look into doing something like > create.insertInto(TABLE).values(Record).toSQL() without binding the > variables or something... Then I could build the batch query myself using > JDBC. Then I could use Record.intoArray() or something to build the > parameter list.... Yes, you can use Query.getSQL() and Query.getBindValues() from an INSERT statement: http://www.jooq.org/javadoc/latest/org/jooq/Query.html#getSQL() http://www.jooq.org/javadoc/latest/org/jooq/Query.html#getBindValues() You can also "intercept" the query that would be rendered by Record.store(), via ExecuteListeners: http://www.jooq.org/doc/3.0/manual/sql-execution/execute-listeners/ Just throw an exception once the SQL statement has been rendered, preventing its execution. org.jooq.impl.BatchCRUD has a QueryCollector, which roughly looks like this: /** * Collect queries * <p> * The query collector intercepts query execution after rendering. This * allows for rendering SQL according to the specific logic contained in * TableRecords without actually executing that SQL */ private static class QueryCollector extends DefaultExecuteListener { /** * Generated UID */ private static final long serialVersionUID = 7399239846062763212L; @Override public void renderEnd(ExecuteContext ctx) { throw new QueryCollectorException(ctx.sql(), ctx.query()); } } /** * A query execution interception signal * <p> * This exception is used as a signal for jOOQ's internals to abort query * execution, and return generated SQL back to batch execution */ private static class QueryCollectorException extends RuntimeException { /** * Generated UID */ private static final long serialVersionUID = -9047250761846931903L; private final String sql; private final Query query; QueryCollectorException(String sql, Query query) { this.sql = sql; this.query = query; } String getSQL() { return sql; } Query getQuery() { return query; } } Taken from: https://github.com/jOOQ/jOOQ/blob/master/jOOQ/src/main/java/org/jooq/impl/BatchCRUD.java -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
