Hmm, I wonder though, if jOOQ should maintain a ThreadLocal somewhere,
referencing the Configuration for query / routine execution, instead of
attaching things... This would result in the following use-cases:
Creating attached objects and executing them:
==================================
DSL.using(...).select().from(...).fetch();
This will behave as today, for backwards-compatibility reasons. Queries
created through DSLContext will be attached to their creating Configuration
and execute themselves in the context of such a Configuration
Creating unattached objects and executing them:
==================================
DSL.using(...).fetch(
select().from(...)
)
This will no longer attach the argument query, but pull a Configuration
from a ThreadLocal that is set (and unset) in the DSLContext.fetch() method
Executing queries in a "block"
==================================
The above distinction would then allow for creating blocks around several
queries. In the long run, such a model might allow for transaction
listeners and other useful SPI:
DSL.using(...).run(new Runnable() {
public void run() {
// These methods pull a Configuration from a ThreadLocal
select().from(...).fetch();
insertInto().values(...).execute();
}
});
Such blocks would also be very convenient to use with Java 8 lambdas:
DSL.using(...).run(() -> {
// These methods pull a Configuration from a ThreadLocal
select().from(...).fetch();
insertInto().values(...).execute();
});
Supporting such blocks would allow for nesting blocks. Hence, the
ThreadLocal would really be a ThreadLocal<Deque<Configuration>>, keeping
track of the nesting of Configurations / blocks.
Consequences
==================================
This would mean that jOOQ would:
1. Use an attached Configuration if available, for backwards-compatibility
reasons
2. Try to get a Configuration from a ThreadLocal, if the current Query is
not "attached"
3. Throw a DetachedException (or similar) if both of the above fail.
Such a solution would allow for a smooth transition towards jOOQ 4.0, when
later versions of jOOQ 3.x could deprecate DSLContext's various Query
construction DSL entry points, indicating that attaching queries will
eventually not be supported anymore.
Such a solution would also allow for using jOOQ in a more threadsafe way,
without resorting to client-side pooling tricks, and without having to wait
for jOOQ 4.0.
And most importantly, such a solution would be transparent, and
backwards-compatible to jOOQ 3.0 and 3.1
Any feedback is welcome. This idea is tracked as: #2732
https://github.com/jOOQ/jOOQ/issues/2732
Cheers
Lukas
2013/9/8 Lukas Eder <[email protected]>
> Hi Eric,
>
> 2013/9/6 Eric Schwarzenbach <[email protected]>
>
>> Hi Lukas,
>>
>> Thanks for your replies. I just want to say that your openness to talking
>> about consider improvements to your API is very refreshing, and an all too
>> rare thing in the software world.
>>
>
> Well, if it wasn't for the great feedback I tend to get on this user group
> (and on GitHub), jOOQ might be only half as good ;-)
>
>
>> I would swear that when I stepped over my bind() call in the debugger I
>> saw a different object returned than the query on which I executed it. I
>> must have misinterpreted something.
>>
>> I'm happy to hear that some of these issues may be addressed in a JOOQ 4,
>> and that there is a way to detach queries. Let me just make sure I'm
>> interpreting your replies correctly around query objects and thread safety.
>> It looks like my options are:
>>
>> 1) don't hold onto a query object, rebuild the query object each time I
>> execute it
>>
>
> That's the easiest way. Or you can pool query objects to add thread-safety
> to them, externally. For instance, using Apache Commons Pool:
> http://commons.apache.org/proper/commons-pool
>
> I'm sure Guava has some nice polling APIs as well.
>
>
>> 2) build it once, extract the sql and hold onto that instead of the query
>> object, and when I want to execute it, instantiate new query object, using
>> DSLContext.resultQuery (in my "select" cases, at least)
>>
>
> Yes, you can do that. Others have successfully used jOOQ as a SQL builder
> only, and executed the statements through Spring JDBC / JdbcTemplate for
> instance. See also:
>
> http://www.jooq.org/doc/3.1/manual/getting-started/use-cases/jooq-as-a-sql-builder-with-code-generation
>
> I personally recommend:
>
> a) profiling to see if there is a significant performance gain in choosing
> that approach (I'd be interested in results!)
> b) carefully assessing if you will then still profit from enough jOOQ
> features. For instance, some type information may be lost when you operate
> on Strings only.
>
>
>> 3) hold onto the query object and synchronize the lines where I attach,
>> bind, and execute (probably not really desirable but just listing it for
>> completeness)
>>
>
> Again, if you want to reuse the query object, I'd personally prefer
> pooling over explicit synchronising. But synchronising will do the job as
> well, of course.
>
> Is that right or are there other options I missed?
>>
>
> Nothing I can think of right now. Of course, as always, the group is
> invited to join and participate, sharing their own experience.
>
> Regards
> 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.
