Witold, Lukas,
> Where
> > to get the "create" from? It doesn't matter.
>
Oh yes it does. If the same object instance is supplied to several calls,
this could result in awful issues in case of multi-threading or usage of
fetchLazy.
The only safe way to execute an SQL call in an application without worrying
of concurrent uses is to call "using()". Only the Configuration is
guaranteed (if not by implementation, by contract) to be a safe object to
use across an application.
> You mean that org.jooq.DSL shouldn't do two things at once.
I agree with Witold here, as you know. For me, JOOQ maps SQL to Java and
the DSL aspect of JOOQ is what makes it possible. But the using() keyword
is breaking this mapping. This is why I said there should be a DSL that
maps the SQL call, and a DSL to map the rendering call. This addition of
"using" to the SQL mapping DSL is something for the lazy, which rots the
API, confuses users with regards to intent, etc. I will stop here before I
am going to repeat myself too much, and I also understand the difference in
point of view :)
Lukas, would it be possible to add a method for those who want to make that
distinction? I am looking for a DSL like:
load(configuration).bind(Query).execute()
where:
- "load()" could be in "DSL" (since "using" is there...)
- would return an interface that only exposes bind() which implementation
can be shared (only configuration is stored, which is global/sharable).
- bind() returns an interface with only rendering capabilties (which
DSLContext can implement, and which DSLContextImpl can actually be the
underlying object that is returned) and which is a contextual object (not
to be shared).
Keep up the good work! :)
Cheers,
-Christopher
--
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.
