Hi Christopher,
2013/4/5 Christopher Deckers <[email protected]>:
> Hi Lukas,
>
> I strongly think there should not be a duplication of Factory (JooqDsl)
> methods to the Executor type. I really think that separation of concern
> should prevail:
> - One entry point to build a query, using a query building DSL.
> - One entry point to rendering a query, using a query rendering DSL.
>
> This would mean having 2 different factories (JooqDsl, JooqRenderingDsl)
> [...]
Sheesh, these frequent changes of terms nowadays ;-)
To get on common grounds again (also for the passive readers of this thread):
- JooqDsl = org.jooq.impl.Factory = "static factory"
- JooqRenderingDsl = org.jooq.impl.Executor (and all its derived
objects, such as RenderContext, BindContext, etc.) = "contextual
factory"
The above terms are understood as of jOOQ 3.0-RC2
> [...] but
> this seems overkill so I think that having a "with" keyword on the JooqDsl
> that returns a JooqRenderingDsl instance is not that bad:
>
> import jooq.org.JooqDsl.*
>
> with(Connection, Dialect).bind(Query).fetch(); or .execute()
So, "bind(Query)" or "define(Query)", this is just a more verbose way
of directly executing the query:
with(Connection, Dialect).fetch(ResultQuery);
with(Connection, Dialect).execute(Query);
Which is just slightly different from today's (jOOQ 3.0-RC2):
new Executor(Connection, Dialect).fetch(ResultQuery);
new Executor(Connection, Dialect).execute(Query);
Or from the previous (jOOQ 2.6):
new Factory(Connection, Dialect).fetch(ResultQuery);
new Factory(Connection, Dialect).execute(Query);
Let's not focus on that aspect too much, as this is already in place
(more or less).
> This would greatly simplify the API, by reducing the number of exposed
> methods, reducing the number of ways to do the same thing, and making a
> clear distinction between which part of the API does what.
>
> Note that I don't think ".bind(Query)" breaks the DSL aspect of JOOQ. It is
> very similar to existing APIs such as ".select(Field...)".
OK, so when we disregard the "define()" / "bind()" sub-discussion,
then your suggestion comes down to removing the "org.jooq.Attachable"
aspect of "org.jooq.Query" in a way that a Query is a "dumb" AST,
which can be manipulated by something we used to call a contextual
factory. By manipulation, we understand things like:
- Rendering SQL to a StringBuilder
- Binding variables to a PreparedStatement
- Executing it
>From this "dumbness" we could conclude that a contextual factory (with
its API partially duplicated from the static factory) would no longer
be needed, and thus, the confusion over the two types would be gone.
We'd be left with a simple type that can do only things like fetch(),
execute(), etc.
Right? If so, yes, you're correct, technically. This would simplify
some of jOOQ's API. I think that this idea first showed up in May 2012
on this user group:
https://groups.google.com/d/msg/jooq-user/hBceRSbufg8/PGn9f4NEt5IJ
This is similar to what CriteriaQuery does in JPA. Some pseudo-code:
// jOOQ
with(...).bind(Query).fetch();
with(...).fetch(Query);
// JPA
em.createQuery(CriteriaQuery).getResultList();
In the early days of jOOQ 3.0, I had explored this possibility. But...
> Or am I missing something?
Yes. In my opinion, you're missing these things:
1. Many users seem to like the fact that queries can execute
themselves. So I want to address this, somehow.
2. This would be quite a bit of a change. Getting rid of "Attachable"
queries (i.e. self-executable queries) isn't simple.
3. It would break semantic versioning, as such big changes aren't
expected between release candidates. Similar to ConnectionProvider,
which had to wait for 3.0
Now, I'm not completely opposed to your idea, and I still haven't
decided for good. Obvious advantages of your approach are:
A. Clean separation of concerns (as recently mentioned also by Joachim)
B. Less (or even no) per-execution state in Query
C. Thus: Closing in on Query thread-safety and reusability
D. Probably many other advantages
But I think that 1), 2), and 3) are good reasons why we shouldn't
change anything substantial here, in jOOQ 3.x, keeping an open mind
for potential options for jOOQ 4.0. If we delve into the clean
separation of API concerns (also: model API vs. DSL API!), we can keep
ourselves busy easily until the end of 2013. I don't want to postpone
the release of row value expressions until then.
Can we agree that we keep discussing these interesting thoughts, but
consider them out of scope for jOOQ 3.0?
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.
