2017-04-10 23:11 GMT+02:00 Hilco Wijbenga <[email protected]>:

> Hi Lukas,
>
> Thank you for this very interesting information.
>
> I would like to understand better how DSLContext and Configuration
> work together.
>

DSLContext is a DSL entry point that operates in the context of a
Configuration, unlike DSL, which is static and context (Configuration) free.


> On 8 April 2017 at 13:00, Lukas Eder <[email protected]> wrote:
> > You've mentioned caching and reflection. One of the most common
> bottlenecks
> > in jOOQ is when you use DSL.using() all the time to implicitly create new
> > Configuration objects, instead of caching the Configuration object (which
> > contains a reflection cache for the DefaultRecordMapper).
>
> Does this paragraph contradict [1]? Let me ask a few specific
> questions (about [1]) to make it, hopefully, easier to respond.
>
> 1) Why not cache the result of "DSL.using(configuration)" and use that
> cached version in the second INSERT? Is there a practical difference?
>

In fact, the paragraph is not entirely accurate. DSL.using(Configuration)
has no significant overhead because DSLContext doesn't really do anything
and this constructor takes a pre-existing Configuration into account.

I've seen quite a few people use the DSL.using(Connection, ...) or
DSL.using(DataSource, ...) convenience constructors all the time, in case
of which a new Configuration is created all the time.


> 2) In fact, why not re-use "create" and avoid
> "DSL.using(configuration)" altogether? Is there a practical
> difference?
>

No. Except that in the documentation, if we did this (and we used to), we
were flooded with tons of questions about what this "create" is.

On a side note, when using injection, the idea is to inject DSLContext,
> correct?
>

That's up to you. You can inject the Configuration, too. Injecting
DSLContext is just a bit more convenient.

-- 
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/d/optout.

Reply via email to