2013/9/10 Eric Schwarzenbach <[email protected]> > > > On Tuesday, September 10, 2013 1:27:19 PM UTC-4, Lukas Eder wrote: >> >> >> >> 2013/9/9 Eric Schwarzenbach <[email protected]> >> >> >>> >>> On Sunday, September 8, 2013 6:34:57 AM UTC-4, Lukas Eder wrote: >>> >> b) carefully assessing if you will then still profit from enough jOOQ >>>> features. For instance, some type information may be lost when you operate >>>> on Strings only. >>>> >>> >>> I haven't yet done any comparisons vs executing the sql via JDBC >>> directly, and am undecided on the tradeoff in functionality. I do find the >>> JOOQ datatype handling functionality to be handy, may just stick with it >>> for that, with the idea that I can always change my code to jdbc execution >>> if it becomes a concern (which I think is unlikely), and that some future >>> JOOQ changes may make query object reconstruction unecessary anyway. FWIW, >>> below is what my proof of concept code looks like at the moment (extracted >>> from my class / method structure for simplicity): >>> >>> Query construction code, executed once during initialization (keep in >>> mind that the tableName, schemaName, and the column name used for the >>> key field are determined at runtime. The jooq generated classes cannot be >>> used directly, and are only used via reflection for column datatypes) : >>> >> >> Interesting approach :-) I think that this reflection might account for >> more overhead than the actual query construction. I guess a lookup >> Map<String, TableField> initialised at application startup might also do >> the trick...? >> > > Yeah, I am only doing the reflection at initialization, and storing the > field datatype (at the moment, in the proof of concept code, a single one, > but it may be a map or such eventually) for use in reconstructing the > query. > >> >> >>> org.jooq.TableField keyFieldDef = ...// use Java reflection to get >>> TableField from the jooq generated classes, >>> ** // from a dynamically sourced >>> column name >>> DataType keyDataType = tf.getDataType(); >>> Param param = DSL.param("key", keyDataType); >>> Condition keyCondition = keyFieldDef.equal(param); >>> >>> ResultQuery<Record> query = DSL.select(getFields(tableName**, >>> true)).from(DSL.tableByName(**schemaName, tableName)) >>> >>> .where(keyCondition); >>> String sql = query.getSQL(); >>> >>> What gets saved in member variables between query executions is only >>> sql, and keyDataType. >>> At execution time (code that may be run by multiple threads) >>> >>> DSLContext create = DSL.using(dataSource, SQLDialect.POSTGRES); >>> Param param = DSL.param("key", keyDataType); >>> ResultQuery<Record> resultQuery = create.resultQuery(sql, param); >>> resultQuery.bind("key", keyValue); >>> Result<Record> result = resultQuery.fetch(); >>> >>> >> Note that Param.setValue() exists: >> http://www.jooq.org/javadoc/**latest/org/jooq/Param.html#**setValue(T)<http://www.jooq.org/javadoc/latest/org/jooq/Param.html#setValue(T)> >> >> Or setConverted() if you may risk data type confusion: >> http://www.jooq.org/javadoc/**latest/org/jooq/Param.html#** >> setConverted(java.lang.Object)<http://www.jooq.org/javadoc/latest/org/jooq/Param.html#setConverted(java.lang.Object)> >> >> That might be a bit better than calling .bind() >> > > Ok. What is the difference? >
.bind() first collects all Params by traversing the AST, looking for Param objects before calling setConverted() on the matching Param object. Since you have a reference to the same Param objects two lines earlier, it might be a bit faster to set the value directly on that Param. I left out the java reflection bit, but can provide that if it's useful to >>> anybody. (I did mean to ask if there is a way to get data type information >>> from the jooq-generated classes without using reflection...that would be >>> handy, too, but mine may be an unusual usecase.) >>> >> >> You can traverse the generated metadata using MY_SCHEMA.getTables() and >> then access each table's fields >> > > Ah! Yes, that's what I needed. That should avoid all need for reflection > except for getting the schema class based on the schema name. Unless there > is some method to list the schema objects somewhere? > Eventually, jOOQ will support catalog code generation. But then you'll still need to discover the catalog somehow :-) Anyway, no there is no schema registry. Regards, Lukas -- 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.
