Hmm. I just realized the the DSL.fieldByName method I was using wasn't the method I thought it was...the parameters I was passing didn't mean to the function what I thought they mean, so no wonder the resultant Field didn't know what type it should be. It's lucky it worked as much as it did!
Most of the difficulties I have run into with JOOQ stem from that I am - using JOOQ code generation, and trying to get the type safety advantages in SQL creation from that, but also - perhaps using JOOQ with usage patterns more typical of someone not using code generation, since there is information coming in from another source that is driving the formulation of queries such that I may be starting from table and column names rather than starting from the objects produced by JOOQ code generation. The DSL object has many methods that look convenient to me but I should probably steer clear of them for two reasons: - the lack of context information that DSLContext can provide (like dialect) - type safety from knowledge of my schema (I can get useful type information from a Field from org.jooq.Table.field(name)...but not from a Field from DSL.fieldByName(...) To answer your question in another thread of how I thought my issue there using Fields that were created by a DSL method not rendering their bit of the SQL as per the dialect from the larger DSLContext-based query construction, related to my question in this thread, well they both relate to whether the Field had some contextual knowledge: in the one case the context from DSLContext, and in the other the context of information from the code generation. (Of course my error with fieldByName may have also affected what I was seeing in the old PostgresSQL sql rendering). On Tuesday, October 8, 2013 3:45:21 AM UTC-4, Lukas Eder wrote: > > > 2013/10/8 Eric Schwarzenbach <[email protected] <javascript:>> > >> It seems that the field that DSL.fieldByName methods return always >> reports java.lang.Object for getType (and, um, "other" or some such for >> getDataType()). >> >> Is this a bug? >> > > If you know the data type of a Field, you can pass it to any of these: > > - > http://www.jooq.org/javadoc/latest/org/jooq/impl/DSL.html#fieldByName(java.lang.Class, > > java.lang.String...) > - > http://www.jooq.org/javadoc/latest/org/jooq/impl/DSL.html#fieldByName(org.jooq.DataType, > > java.lang.String...) > > >> Or is there some notion I'm missing of where information from the >> generated code is and isn't used? >> > > I'm not sure how your question relates to type information from generated > code...? Could you explain, please? > > >> If it's not, for some reason, reasonable to expect DSL methods to make >> use of information from that code generation perhaps there should another >> layer in the class hierarchy for Fields that aren't typed? >> > > Unfortunately, in many SQL dialects and JDBC implementations, Fields will > need type information as ResultSet.getObject() and more importantly, > PreparedStatement.setObject() doesn't work as well as one would hope. Some > insight on that topic can be seen here: > http://blog.jooq.org/2011/08/31/rdbms-bind-variable-casting-madness/ > > In other words, Fields are always typed. If the type is unknown, you may > try your luck with Field<Object> / SQLDataType.OTHER / Types.OTHER and hope > that the JDBC driver and database can handle this. > > Hope this helps, > 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.
