2014-12-02 21:54 GMT+01:00 <[email protected]>: > Thanks for the responses, they really help a great deal. > > *We constantly pass over the manual. Anything you find is greatly > appreciated. We hardly need to read our own manual anymore, so feedback > from users who do read it for the first time is very useful!* > > Manuals should assume no tribal knowledge. People with tribal knowledge > don't read them! > *Because there isn't any surrounding boilerplate code! :-) **With jOOQ, > you don't need any try-with-resources statements. jOOQ manages all JDBC > resources for you, internally (except the JDBC Connection, if you want to > manage that).* > > My confusion with the try-with-resources partially was that some jooq > objects didn't appear to have implemented closeable. >
We are still supporting Java 6, which is why we don't have access to AutoCloseable. We've contemplated implementing Closeable before, but the Closeable contract allows for throwing IOException, which could lead to very weird corner cases. Besides, we couldn't "upgrade" to AutoCloseable any longer, once we unsupport Java 6. > If all I need to do is manage the connection object then that's perfect > and makes me want to use jooq even more. > I'm glad to hear that! Imho they should shoot the guy who invented finally blocks. I was doing > backflips in and out of cubicles when they came out with try-with-resources. > I would have loved to see that! Personally, I wouldn't want to do without finally blocks, but I guess the life of an API implementation developer is different from the API consumer's... > *Is that what you had in mind? Or in what context would you expect us to > provide lambda examples in the manual?* > > In terms of lambdas, a lot of db work obviously involves processing sets > of records which they fit well. I starting to see them employed in > framework documentation everywhere, but when I read the jooq manual I just > have this sense of reading Java 6 code instead of Java 8 code. Felt... > dusty? > You should follow our blog, then :-) If you spot some concrete pages where we could add useful examples, let us know. But beware that most of the manual talks about the DSL and the code generator. There's simply not much use for lambdas there... > *And perhaps includes / excludes patterns. jOOQ is a database-first API, > so yes, it's true that generated objects are inherently tied to the source > database. We see this as a feature, but perhaps we've missed something - > e.g. a specific use-case that we cannot cover yet?* > > Perhaps I'm missing the 'feature' aspect of it. > > A schema is not inherently tied to any physical database but a record > mapping with added validation. Conceptually, I think of them as data > structures in languages such as C, RPG IV or COBOL that you could use as a > template moving it around in memory. There is no reason I can see where a > person should be forcibly restricted from pointing a valid schema > abstraction at multiple connections. I'm sure I'm not the only person in > the world doing a data migration. QueryDSL was able to handle this use > case out of the box, without any further XML configuration. You simply > reference the schema object and the connection when creating the query. > Hmm, this doesn't sound like anything that couldn't be done with jOOQ... Would runtime schema and table mapping have been of any help, then? http://www.jooq.org/doc/latest/manual/sql-building/dsl-context/runtime-schema-mapping/ In principle, jOOQ indeed doesn't care what physical database it runs queries against, and there are lots of means at different levels to implement things like multi-tenancy, mapping, renaming, or even complex SQL transformation... -- 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.
