I feel there is still some confusion left about the purpose of the DSLContext (which was called the Executor in jOOQ 3.0-RC2).
DSLContext is that part of the jOOQ DSL that needs / wraps a Configuration to operate. The important type we're discussing about here is Configuration, not DSLContext. DSLContext just "adapts" Configuration and offers more DSL methods. Some have argued that DSLContext should really be extracted in a separate, independent DSL or API, which I have declared as out of scope for jOOQ 3.0 (without denying that it might be a good idea in a longer run). But apart from wrapping the Configuration, there is no purpose / lifecycle whatsoever related to a DSLContext. In that way, nothing has changed between jOOQ 2.x and 3.x, except for a single DSL method "using()" and the naming: from 2.x's FactoryOperations (which was implemented by Factory) to 3.0's DSLContext (which is implemented privately). Cheers Lukas PS: Christopher, I hope I'll find time soon to reply to your e-mail! 2013/4/8 Durchholz, Joachim <[email protected]>: >> Sharing a configuration object across entire application just >> to be able to get an Executor in return, is an anti-pattern, >> it is evil and every time when someone suggest to do so, an >> innocent kitten dies. > > Well, you do have context objects like that all over the place: > - JDBC connections > - Hibernate (or other ORM) sessions > - File handles > - Network connections > > Yes, they are evil. One of the main reasons for the existence of frameworks > like Spring is the injection of such "resource" objects. > > However, they are unavoidable for the following purposes: > 1) To allow replacing the context underneath a computation. E.g. run the same > JDBC on top of different databases. > 2) To avoid recreating the context for every operation. > > For Jooq, the litmus test is: > Would it be useful to have a variant of Executor that takes its parameters > not from a configuration object but from a set of parameters? > How "wide" would that interface be? ("wide" = "many" parameters, or > parameters with "complex interrelationships".) > Would you want to use overloading on Executor constructors? Would overloading > run into uniqueness issues? > > In the latter case, you need a Configuration construction kit anyway; the > best remedy would be to make it do very little processing, postponing all the > heavy lifting to the point in time when the query is actually executed. > However, this approach also delays any error checking until execution time, > which is unhelpful for finding bug causes. > > Designing such interfaces is a trade-off between a LOT of conflicting goals, > and sometimes it's the choice between killing kittens and seal babies; the > art of design is to find a compromise where you kill neither (but maybe > somewhere else a hyena baby starves - no matter what you do, some trade-offs > simply do not have an answer that can't be questioned). > > Regards, > Jo > > -- > 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.
