Hi Lukas,
I wish to exclude the DSLContext / Executor from these thoughts. It is
> complicating things unnecessarily. It has no state / lifecycle of its
> own. Introducing it in the way I originally did was confusing. The
> thought of having "new Executor" along with the name "Executor" seemed
> to indicate that it has a life of its own. It doesn't. It had a 1-to-1
> relationship with Configuration, adding DSL capabilities.
Configuration does not expose methods with Connection. DSLContext creation
does, which means it is not safe to use because it may have a state
(especially if the part of the application a developer is working on is
independant from the part of the API that creates the DSLContext).
JOOQ could garantee this by having only one "using" method:
using(Configuration).
For quick runs of queries that do not need listeners (and other
Configuration stuff), you could have something like:
new UnsafeConfiguration(Connection, Dialect)
which lazy users could use:
using(new UnsafeConfiguration(Connection, Dialect))
This would clearly show the intent, warn the users, etc. They would know
that sharing the resulting Configuration may be dangerous (and its Javadoc
would document why it is unsafe, because of the way it provides
connections).
> As I will
> explain further down, everything you want to do can be done without
> allowing "Executor" to have its own lifecycle.
>
It can, but it is not guaranteed. When 20-50 developers work on the same
business application, with many modules and so on, you can only rely on the
hard rules set by libraries. If a rule is not clear or has several
different meaning, it is dangerous, especially if that library is used
throughout the whole application.
If I were the only developer on the applications I work on, I wouldn't care
:)
I agree. Although, I think that the ConnectionProvider *should* be
> loose to cover all use cases.
>
By being loose, you prevent use cases (like 3rd party tools taking a
Configuration as a parameter to use connections for their own needs, a 3rd
party execute listener that needs a dedicated connection, etc.).
Please, show me a use case where being loose helps compared to having the
hard rule of "acquire" always returning a dedicated connection?
I know you want to be loose on every aspects, but that results in a fuzzy
API where multi-developers project cannot make assumptions (or wrong ones).
These unspecified aspects then have to be handled through company policies,
provided the issues are identified, and may be occasionaly overlooked
(blowing up in production of course).
Yes, it is hard to get it right. Do note that this was much harder to
> get right before jOOQ 3.0, before the introduction of a
> ConnectionProvider. In order to get it right, a properly pooled (and
> thus shareable) DataSource was needed.
>
I am not sure how connections taken from a DataSource are supposed to be
returned to their pool. Any experience on real applications using
DataSource to explain the lifecycle?
B) jOOQ can provide default implementations for the
> ExecuteListenerFactory, e.g. a DefaultExecuteListenerFactory, which
> would contain a constant list of ExecuteListeners.
Let's take the example of the DebuggerListener. How should I code it? The
whole point of the factory is so that DebuggerListener is a new instance
per run and thus can retain state. How would JOOQ instanciate it if it were
to automatically use such kind of stateful listener but wanted a static
list of listeners?
> I don't think that we need the additional complexity by adding
> the possibility of creating "per-Executor" setups.
By-the-way, I agree to that, I just mentioned it to cover all cases from
global to specific.
> If you feel that there is still a missing piece as I might not have
> gotten the full picture yet (e.g. contracts too loose, additional
> lifecycle for DSLContext), feel free to continue this discussion.
>
I wonder whether we understand each other, because you say:
- Loose contracts allow more flexibility.
- Hard contracts make them hard to implement.
which is in opposition with what I say:
- Hard contracts do not restrict flexibility.
- Hard contracts remove ambiguity: any tool/developer knows how to
use/implement without mistakes.
- Loose contract lead to API misuse, bugs and potential bureaucracy.
Hope this helps,
-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.
