Hi Lukas,

Sarcasm mode: on
(yeah, I am trying to be nastier than last time!)


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);
>

You are right, now I am coding all my applications in a single class. No
more verbosity!

Also, I found that auto executing things in unrelated context is a
wonderful idea, so I am suggesting Oracle to change:
SwingUtilities.invokeLater(Runnable)
to:
Runnable.invokeInSwing()

Yes, it is less verbose too.



> 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);
>

Just so I don't forget about it, there are many ways to do certain
operations in the JDK. For example:
SwingUtilities.invokeLater(Runnable);
EventQueue.invokeLater(Runnable);
and whenever there is such duplication, people lose their time arguing
which one is the best practice. You should try to prevent that.



> 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
>

That is exactly my view.



> 1. Many users seem to like the fact that queries can execute
> themselves. So I want to address this, somehow.
>

There is no difference between:
run(query)
and
query.run()

This is not a valid point, users wouldn't mind (unless they go on strike to
save one character).



> 2. This would be quite a bit of a change. Getting rid of "Attachable"
> queries (i.e. self-executable queries) isn't simple.
>

This is where your skills come into play :)



> 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
>

OK, let's assume "RC" meant "Release Confirmation". I confirm that there
are a few changes that would be welcome before we reach Release Candidate.

I believe not many users moved to 3.0 RC. Most users would transition from
2.0 to 3.0 when it is final. After migrating all their code, they will see
that 4.0 has another approach. My feeling is that as long as 3.0 is not
official, things can change and should change. Further releases should be
less painful if design is right from now on.



> I don't want to postpone
> the release of row value expressions until then.
>

This is already released, people can use RC 2 if they want it now ;)


Can we agree that we keep discussing these interesting thoughts, but
> consider them out of scope for jOOQ 3.0?
>

I don't have to agree, you are the benevolent dictator and you have to take
decisions! :)

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.


Reply via email to