Hi Witold, This criticism has been well received and is being worked into 3.0-RC3. There will probably be no "Executor" for two reasons:
1. The name is inadequate. It is really just intended to be a "contextual Factory" (whose name is also inadequate). 2. There should only be a single point of entry: The Factory. What is currently called "Executor" should be created by that Factory as well, wrapping the Configuration. The most relevant recent discussion is this one here: https://groups.google.com/d/msg/jooq-user/uxcYEC7IoDM/_ytimZlE9iMJ It is very likely that I will implement something like: with(configuration) // or other arguments .select(...) .from(...) ... Where "with()" is a Factory method (or DSL entry point method). Cheers Lukas 2013/4/5 Witold Szczerba <[email protected]> > Hi, > I have been browsing through the mailing list recently, but did not have > time to see the JavaDoc yet. > > Few minutes ago, I have written a word about the impl.Factory in request > for feedback topic. > > Now I look at the API and I can see the Executor is not an interface (as I > though) but it is a "dot impl" class. There is no equivalent of > FactoryOperations interface from version 2.6. > > What is wrong with this is that class is a mix of two things which should > never coexist in one place in applications. The construction of objects > should never be mixed in one place with the code which uses them. At least > this is what I believe. > > How many times, in a typical database application, are we going to use the > Executor instances? Hundreds maybe (every time we deal with database). And > in how many places are we supposed to provide a block of code which > assembles executor instance? Most of the time it would be one, I guess. > Maybe two if we are dealing with more than one database. > > If a class wants to have an access to the database through Jooq Executor, > it asks for an instance and does not care who and how creates it. It would > be nice if that class would not care about the implementation (for example: > is it a real database executor or some kind of a mock/stub, if any), that > is why it should be an interface. > > Also, it is easier to deal with interfaces in some Dependency Injection > containers like CDI. > > What do you think? Is it possible to extract all the Executor methods > (excluding the ones from Configuration interface) and move them to the > interface? Maybe the Executor would be better name for that interface and > the current Executor would be renamed to something else and unimportant as > regular JOOQ user would never have to deal with it, excluding one place in > their code where they instruct application how to gen instance of the > Executor interface. > > Regards, > Witold Szczerba > > -- > 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.
