Hello, Thank you very much for your valuable feedback. I will comment to your different points inline
2014-12-02 15:39 GMT+01:00 <[email protected]>: > > > On Thursday, November 27, 2014 7:31:14 AM UTC-5, Lukas Eder wrote: >> >> On a more serious note (sorry, couldn't resist 5 minutes ago) >> >> I'm sorry to see you go because of this. I do believe that you will find >> the missing features limiting after a while, but I certainly understand >> that moving a project forward can be essential. >> I'm curious about the "bit slower" part. How does this manifest? >> >>> >>> >> This project was just a database migration, so QueryDsl worked. Less > features true, but the overall interface was simpler as a result. QueryDSL > doesn't really have a manual like Jooq does, but I didn't need one. > Fair enough > I hope you find time to make a pass over the manual by the time I come > back. > 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! > I *really *want to use Jooq for crud, but most of the examples look like > Java 5-6 era and are in serious need of being brought up to date. Other > than my binding issue, I couldn't find an example that used try with > resources in the manual, as everything is missing surrounding boilerplate > code. > 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). Perhaps this page might help understand what I'm trying to say: http://www.jooq.org/doc/latest/manual/sql-execution/comparison-with-jdbc/ We have inversed all default behaviour compared to JDBC. We believe that most of the time, you don't want to keep open PreparedStatements or ResultSets. You want to dispose of those things immediately at execution time, keeping reference only to a Query object and the Result data. Of course, if you intend to keep those objects open, you can do so explicitly, but 95% of the time, the boilerplate that is produced because of this is tedious and unnecessary. Let me know if this makes sense, or if you were looking for something else. > I also couldn't find an example that leveraged lambda expressions. > There are a couple of ways to leverage lambdas once you have materialised a jOOQ Result. We've blogged about that a couple of times. Some examples: - http://blog.jooq.org/2014/04/11/java-8-friday-no-more-need-for-orms/ - http://blog.jooq.org/2014/07/11/java-8-friday-more-functional-relational-transformation/ Other examples would involve CompletableFutures, if you want asynchronous query execution: - http://blog.jooq.org/2014/09/23/asynchronous-sql-execution-with-jooq-and-java-8s-completablefuture/ But those usages are merely possible because jOOQ Result or ResultQuery implement standard JDK APIs, such as List (Result) or Iterable (ResultQuery). There is not really any other explicit use for lambdas in the jOOQ API, except perhaps when using RecordMapper: http://www.jooq.org/doc/latest/manual/sql-execution/fetching/recordmapper/ Is that what you had in mind? Or in what context would you expect us to provide lambda examples in the manual? Nor could I find out the best practices in using the same schema for two > different databases. It worked out of the box with querydsl, but jooq > didn't appear to like it at all. Unlike QueryDSL, the jooq generated java > objects appeared inherently tied to the source database My workaround was > to generate two separate schemas, renaming the mysql enum fields on the > target db. Not pretty, but it did work! > I'm not 100% sure what you mean by this. You have installed two different logical databases in the same schema? The best way to deal with this sort of multi-tenancy via the jOOQ code generator is by using schema mapping: http://www.jooq.org/doc/latest/manual/code-generation/schema-mapping/ 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? Best 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/d/optout.
