Hi Christopher,

>> > I was wondering if the same method could be both contextual and static, but
>> > I am not sure whether there are so many cases that justify it. Since it 
>> > used
>> > to be that way (2.x) you have more practical experience so I can't really
>> > argue.
>
> I think I was not clear with what I was trying to say: do we really need both 
> contextual and static methods with different intent whether contextual and 
> static?

So I guess I didn't understand you here. And probably still don't.
What do you mean by the above?

>> I would really really regret losing the ability to just append
>> ".fetch()", ".execute()", and all the other many methods to a Query /
>> ResultQuery in a fluent style.
>
> So, all this complexity comes from the fact that you want fluency in crafting 
> the query AND running it, from the same chain.

If you want to call it "complexity". Yes, that's the reason why the
API entry points are duplicated as of now. Many users like the way
things are - except for the confusion about the Executor.

> Let's think of an alternative fluent-like way that expresses query definition 
> (static) and it's contextual usage.
>
> Assume "import static org.jooq.impl.Factory.*", and I will also use your 
> "with" approach :)
>
> with(connection, dialect).define(
>
>     batch(
>         insertInto(TABLE_A).values(1, 2, 3),
>         insertInto(TABLE_B).values(4, 5, 6)
>     )
> ).execute();

That's not much different from the following, which you can already do today:

    new Executor(connection, dialect).batch(
      insertInto(TABLE_A).values(1, 2, 3),
      insertInto(TABLE_B).values(4, 5, 6)
    ).execute();

If I introduce Factory.with() methods, this can be phrased alternatively:

    with(connection, dialect).batch(
      insertInto(TABLE_A).values(1, 2, 3),
      insertInto(TABLE_B).values(4, 5, 6)
    ).execute();

I don't think there is any need for an additional "define" keyword in the DSL.

>> >> Topic #2: "Executor" as a name
>> >> ==============================
>>
>> It has. Strong and emotional ones :-) So I'm looking forward to your
>> elaboration.
>
> I still want to clear topic #1 first :)

What's left to clear? I think you're putting too much weight into the
Executor. While it sounds like an important API element, it's just
another "XXXStep" class. With an unfortunate name. It has absolutely
no meaning / lifecycle / weight, except maybe some historic one, which
I'm about to remove. E.g. in 3.0-RC3, Executor will no longer
implement Configuration, but contain one (although, I'm not even sure
about that...)

>> I know. I hate the java.awt.List as much as you do.
>
> Thanks. I take that as a "you have a point, somehow" :)
>
>> Thanks. I take that as an "I give up (on the Factory name discussion)" :-)
>
> Well, whatever!

You know, I was just kidding. We're clear about "Executor", which I'll
work into the DSL API. But I'll create a new thread on the user group
to collect compelling alternatives to "Factory". I won't put much
effort into finding one myself, but maybe someone has an inspiration.

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.


Reply via email to