2013/4/5 Christopher Deckers <[email protected]>:
> 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.
Actually, this example doesn't work, as Runnable is really not
supposed to know about Swing. The responsibilities are clearly
defined. Whereas adding a convenience method "fetch(ResultQuery)" to
the result of "with(...)" that internally calls something like
"this.bind(ResultQuery).fetch()" is really not such a bad idea. As a
matter of fact, jOOQ does that all the time. E.g.
select().from(T).join(U).on(...)
The join() here is nothing else than
select().from( T.join(U).on(...) )
>> 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.
Let's leave this out. "define()" / "bind()" is really not the main topic, here.
>> 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.
At least we understand our points of 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()
There's also no difference between
for (int i = 0; i < 10; i++);
and
int i = 0;
while (i < 10) i++;
Let's ask Oracle to remove the latter. And while we're add it, we
should remove the for-each loop too, and who needs the
try-with-resources construct? Or jOOQ, when we have JDBC? ;-)
> This is not a valid point, users wouldn't mind (unless they go on strike to
> save one character).
Have you actually asked the users? :-)
Some do mind. Some just don't agree.
>> 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 :)
Hah, yeah. :-) Easy for you to say.
>> 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 had published many snapshots for review, the group was very quiet,
then. The group was also very quiet when I released RC1.
> 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.
Yes, that's true. Things can change, but now they're simply not going
to change drastically any longer.
jOOQ's design isn't specified by a large EG in a JSR, it evolves
slowly. Be aware that even if you disagree with many concepts right
now, things are actually much better than they used to be in 2.x
(where contextual and static API was mixed in one class, and
everything was "attachable", etc, etc)
>> 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! :)
Precisely! Hehe, the benevolent dictator... Do note that APIs that
evolve from large EG's aren't necessarily much better :-)
Anyway, as we're delving into sarcasm here, I'll call it a day,
re-iterate my thinking, and we'll see how long 3.0 should be
postponed, or if things can wait for 4.0.
--
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.
