Hello, > Can't say... I hate JPA annotations soooo much. However if they are > generated, perhaps I could live with.
Well, I understand those feelings, but JPA annotations are quite expressive. In my opinion, JPA went wrong in the way they assumed that SQL should be drastically reduced to JPQL, which in turn can be generated from those annotations. But the annotations themselves can be useful (to some) > I am not sure that graph loading strategy would fit very well in the current > API which is fully SQL centered. I don't see a contradiction. Note that all "graph loading" would be performed in memory within the org.jooq.Result and org.jooq.Record types. Already today, this is a "convenience extension" to jOOQ's main feature, the SQL DSL. Already today, the two "models" co-exist. Most of it is documented here in the Javadoc: http://www.jooq.org/javadoc/latest/org/jooq/Record.html#into(java.lang.Class) Adding more features to that into() method wouldn't change the behaviour of the DSL. Your expressed SQL would still be very predictable. jOOQ will always first fetch a table representation of your data into org.jooq.Result. Only then, some transformation may take place. > When dealing with entities, say you want customers with their orders, you > know that if any joins are needed, you'll most likely need left joins or > perhaps INNER in case there's a condition involving another table, if you > want your queries to fit in a graph model in some predictable way you can't > really give total freedom regarding the SQL. Precisely. The decision should remain with the jOOQ client code. > My advice then would be to > always use IN or Subqueries to load a graph in order to avoid cartesian > products and excessive duplicate elimination. True, duplicate elimination could be a problem for large queries. But as always, performance problems shouldn't be the driving force for an API. There can still be a solution to that problem later on (e.g. "merging" or "joining" org.jooq.Result objects in memory) > In llblgen, relations were > always loaded using suqueries even the one-to-one where JOINs would have > been more efficient, it was not often a big drawback and even so you could > use typed queries or views when performance was the main concern. I see. But again, I don't think jOOQ should generate any additional SQL just because you want to fetch "child" records (orders) or your "main" record (customers). jOOQ users should be in full control of any SQL executed. An important reason why this is so is the fact that jOOQ already renders / simulates a lot of SQL, internally. An example for this is the simulation of the LIMIT .. OFFSET clause for databases like Oracle, SQL Server, Sybase, DB2. I also have plans of simulating - CUBE(), ROLLUP(), GROUPING SETS() using UNION ALL - Oracle's CONNECT BY using recursive common table expressions - FULL OUTER JOIN using UNION ALL - etc... If a result-table-to-Java mapping strategy would play into these delicate query transformation features, I'd probably open pandora's box. > Because jooq current API is SQL centered and does its job well perhaps it > should stick to that, I would say that an llblgen style entity/graph system > built on top of that may actually be better than adapting the current API to > add the necessary logic. Precisely. jOOQ's SQL API will stick to SQL. The "mapping" API (or perhaps, ORM API) is only contained in org.jooq.Result and org.jooq.Record. The two will not interfere. > Well it is just an idea thrown on the table but sometimes, things are better > when they stay separated... Don't worry. > PS: I have just realized you're near Zurich, You have my greetings from the > Valais ;-) Great! You should join me at the JUGS in Berne, then! The one in Zurich was quite interesting: http://www.jug.ch/html/events/2012/jooq.html I'm not sure about the date though, yet. Cheers Lukas
