Hi Max, 2016-01-12 16:47 GMT+01:00 Max Kremer <[email protected]>:
> Hi Lukas, > > As always thank you for the prompt and detailed reply. Looking at the > JOOQ type system is becomes clear why the need for various local types are > not needed (everything is a subtype of Table). > Sure, you're welcome :) Yes, that type system hierarchy may not appear obvious. But it is a good thing to remember that the Step types are only auxiliary types. Whenever you have a syntactially correct epression, that expression will extend the useful super type, e.g. Table<?> > Your example with generating conditions is very similar to how I do it > now... However its the JOIN stuff that's giving me grief right now. Joins > are more complicated because of the many permutations of tables that can > participate in the join, and depending on which tables participate I need > to perform the join differently. > > Let's say for example you have 3 tables Events, Sessions and People. There > are 2^3 - 1 = 7 valid combinations of these 3 tables. (minus one for zero > tables). > > Once a table is joined in the query I don't know if there is a good way to > get at that information after the fact (getQuery?). For example, if I'm > joining Session it would be good to know if Person has already been joined > because then I can do *Session.personid = Person.id*, but if it is only > Event that exists in the join then I need to do *Event.sessionid = > Sessions.id *and if no tables exists so far then there is join and I'm > simply querying the Session table. > Hmm, I see. You should probably look at this problem from a graph theory perspective. Your join predicates are edges between your tables, which are the vertices. Perhaps, you could model your dynamic joins this way: As a graph. And when you "collect" the graph, it will be much easier to decide what tables and what predicates are needed. I don't know your full requirements, but I'd be very interested in learning more. Perhaps there is something fundamental that could be implemented in jOOQ...? > Is there a way to get a list of the tables in the join or do I need to > wrap the query generation logic with something that keeps track oft this > for me? > No, right now, you can no longer extract these things from the Query, unless you implement a VisitListener. Tracking objects yourself prior to adding them will be much simpler, though. > I'm trying to avoid building a giant case statement that accounts for all > the permutations. I suppose the questions is less of a JOOQ questions and > more of a general design question... > Well, it is a jOOQ question, because perhaps, we can add a new, awesome feature in this area! -- 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.
