Hi Gérald, I know that many other frameworks (e.g. LINQ, Slick, QueryDSL) try to solve this SQL "problem" by inverting the order of clauses to what should have been done in SQL from the beginning. Unfortunately, that particular solution is usually incorrect. I've described this here (item 2): http://tech.pro/tutorial/1555/10-easy-steps-to-a-complete-understanding-of-sql
SELECT is actually not the last clause in a SQL statement, which is "logically" ordered as such (only most important clauses only): - FROM - WHERE - GROUP BY - HAVING - SELECT - DISTINCT - UNION - ORDER BY - OFFSET / FETCH By artificially moving SELECT to the end, many other frameworks will diverge from actual SQL in edge-cases. In any case, the inversion wouldn't change anything here. As I mentioned before, the only missing part is to be able to select BOOK.*. This feature is on the roadmap for jOOQ 3.3: https://github.com/jOOQ/jOOQ/issues/2769 With that implemented, it might be possible to fetch typesafe BookRecords even if joins are present. Hope this helps, Lukas 2013/12/2 Gérald Quintana <[email protected]> > Hello, > > The logical syntax may be useful here: > Result<BookRecord> bookRecords=jooq.from(BOOK) > .join(AUTHOR).on(BOOK.AUTHOR_ID.eq(AUTHOR.ID)) > .where(AUTHOR.NAME.eq("Victor Hugo")) > .select(BOOK) // Meaning select book.* > .fetch(); > Since select() is close to fetch(), it may be easier to keep type > information. > Is there a technical reason (in API design or whatever) preventing logical > syntax? > > It's only an idea, probably a blind one. > > Gérald > > > Le dimanche 1 décembre 2013 15:16:08 UTC+1, Lukas Eder a écrit : >> >> Hi Aurélien, >> >> Aha, I can see the point of confusion. The problem here is that jOOQ >> currently doesn't really support selecting t.*. By writing >> select().from(t.join(u).on(...)), you're implicitly selecting t.*, u.*. >> Now even if jOOQ checked the explicit projection at runtime to see if t.* >> is being completely selected, this would not lead to generic typesafety in >> Java, thus you'd still get a Result<Record> or maybe, a >> Result<Record[N]<T1, T2, ..., T[N]>> >> >> In other words, this is an API limitation / flaw of jOOQ. I currently >> don't know how this could be resolved. As always, I'm very open to >> suggestions. >> >> Cheers >> Lukas >> >> 2013/11/30 Aurélien Manteaux <[email protected]> >> >>> Hi Lucas, >>> >>> I don't understand when you say that once you join other table the >>> specific table type would get lost. >>> For example : >>> - SELECT t.* FROM Table1 t => the result type is Table1 >>> - SELECT t.* FROM Table1 t JOIN Table2 k ON t.id=k.tid => the result >>> type is still Table1 >>> >>> Am I missing something ? >>> >>> Cheers, >>> >>> Aurélien >>> >>> On Saturday, November 16, 2013 12:03:45 PM UTC+1, Lukas Eder wrote: >>> >>>> Hi Gérald, >>>> >>>> 2013/11/16 Gérald Quintana <[email protected]> >>>> >>>> Hello, >>>>> >>>>> Actually, the question was: why can't I use joins when using >>>>> selectFrom statement? >>>>> >>>> >>>> Hmm, yes, I was going to explain that but somehow I forgot... >>>> >>>> The idea is simple (although debatable). The idea behind selectFrom() >>>> is to provide jOOQ with a clearly defined record type, which may be a more >>>> specific type than for instance Record2<Integer, String>. Once you join >>>> other tables, that specific table type would get lost (i.e. denormalised). >>>> Since selectFrom() offers no way to redefine the projection (SELECT >>>> clause), the result would inevitably be the type-unsafe Record. >>>> >>>> There's certainly room for API improvement in that area. I'm open to >>>> suggestions. >>>> >>>> At first, I thought that "selectFrom(SOURCE).fetchInto(TARGET)" meant >>>>> "insert into TARGET (...) select .. from SOURCE". >>>>> >>>> >>>> Aha. No that would be insertInto(TARGET).select(...) >>>> >>>> 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. >>> >> >> -- > 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. > -- 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.
