2013/12/5 Gérald Quintana <[email protected]> > Thanks for this explanation, > > I thought the problem was the selected record type was lost after joining > other tables. When I say "lost", I mean from type safety (java generics) > point of view. >
Well, it isn't lost, but there is the table reference type (in the FROM clause) and the projection (in the SELECT) clause. The two are contradictory, and even a GROUP BY, or a PIVOT or some other vendor-specific clause can transform the row type in between. If, however, a new select() overload can be added that takes an "asterisk type" (or whatever the name will be), then the BookRecord type information won't be lost. In fact, we could even imagine selecting BOOK.*, a, b, c, AUTHOR.* into something like <BookRecord, Integer, String, Integer, AuthorRecord>. I haven't gone through the API design exercise on that yet, though. > I knew that select wasn't the last part in logical order, but most of > remaining parts (distinct/order/offset) do not change the record type, the > exception is probably union here. From my Java developer point of view, > getting select (=projection) and fetch (=row mapping) close is interesting > because both are related: when there is a lot of code between select an > fetch, the code gets less readable. > Yes, it certainly is more readable. I guess that the early SQL designers regret this language design decision. And some other things, too :-) > I'll try to stop arguing about this since I am not relevant ;-) . > Hehe, well, you can always try :-) Cheers 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.
