Oh, yes, that was the very long thread, I have lost my way going through
it, hehe :)
As to the:
with(configuration)
.select....
Is this a real use case? I mean, in any given class responsible for talking
to database, why should I care about configuration object, if all I need is
the other object (factory instance), exchanged for configuration instance?
I believe (am I alone?), each class should ask only for things it does care
for. In the case above, we do not care about configuration, we care about
that contextual factory instance. All we use configuration for, is to
quickly exchange it for something else. That means we should never ask for
a configuration, but the contextual factory instance (or a provider of
that) instead.
Of course, having the code you provided I can create a provider or a
producer like this:
//you are right, the name ContextualFacotry is not fortunate...
Provider<ContextualFactory> {
ContextualFactory get() {
Configuration config = ...get it from somewhere...
return with(config);
}
}
MyClassTalkingToDatabase {
@Inject ContextualFactory jooq;
//or like this, depends on this instances lifecycle
@Inject Provider<ContextualFactory> jooq;
Something get(...) {
return jooq.select(...).fetch....
// or if provider was used explicitly, ugly and can always be avoided:
jooq.get().select(...).fetch.... but this can always be exchanged for
the direct use above
}
}
The good news is, now it is possible to easily separate the
"with(configuration)", which is going to be exactly the same all over the
place in entire application, for a provider. The question remains: is the
contextual factory an interface like FactoryOperations was in JOOQ 2.6?
Regards,
Witold Szczerba
On 5 April 2013 13:56, Lukas Eder <[email protected]> wrote:
> 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.
>
>
>
--
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.
