Hi Ben, 2015-12-30 20:16 GMT+01:00 Ben Hood <[email protected]>:
> On Wed, Dec 30, 2015 at 12:34 PM, Lukas Eder <[email protected]> wrote: > > No. Maybe in jOOQ 5.0 :-) > > OK, cool - then this means that is fair to say that JOOQ is a JDBC > tool. Right now, yes it is. jOOQ doesn't hide JDBC and is semantically very close to JDBC, apart from different defaults being applied when it comes to lazy or eager fetching / closing resources. This is also described here: http://www.jooq.org/doc/latest/manual/sql-execution/comparison-with-jdbc/ > If that is the case I would like to see less assumptions being > made by the JOOQ runtime about how an app wants to interact with the > DB with a transaction. But in fairness, my comment is a bit off topic > - this thread is about the code generator, not the runtime. > Yes, the thread will become a bit confusing, but I'm curious about your feedback anyway. Perhaps start a new thread? I think we still have some spare threads left on Google Groups ;-) > Interesting feedback. So, were you really missing something from the > runtime > > library or from the code generator? > > When I mentioned type index I was talking about the private maps > TYPES_BY_NAME, TYPES_BY_TYPE and TYPES_BY_SQL_DATATYPE which are all > immutable to the third party code during code generation and at > runtime. Oh I see, yes. There is some bad design in the data type implementation from very early on. This definitely needs to be improved in jOOQ 4.0 > What I'd like to be able to do is to write into these maps so > that > It's better not to open up access to these maps and let you depend on the existing, bad design. We'd rather figure out what would be a better design. (a) I don't have to override JavaGenerator on a per-column basis to > shadow the output of these immutable indexes If I understand this correctly, we're still discussing the workaround that you implemented and that you'd like to improve. But what is the *use-case*? What are you trying to achieve and why doesn't it work right now? (b) When I generate field references for complex queries at runtime, > that the DSL.field() call can be aware of my custom type - this is > another instance where the immutable type map leads to bogus SQL being > generated at runtime. You can. Write DSL.field("...", SQLDataType.VARCHAR.asConvertedDataType(bindingOrConverter)) I'm sensing that we'll spawn off another discussion here about (b), that is about improving this API...? (as it isn't really related to the code generator) -- 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/d/optout.
