Good point. As for now, these kinds of clauses are not yet supported.
I will schedule an improvement in a future release:
https://sourceforge.net/apps/trac/jooq/ticket/420
In the mean time, I think you will have to fall back to a workaround.
Either you can try to use a plain SQL object (admittedly, not a very
nice workaround), or you create a wrapper for Select<?>, adding the
additional SQL at the end.
You would have to create something like this:
// ------------------------------------
class SelectForUpdate implements Select<Record> {
private final Select<Record> delegate;
// ... delegate all methods to "delegate"
@Override
public String toSQLReference(Configuration configuration) {
return delegate.toSQLReference(configuration) + " FOR UPDATE";
}
}
// ------------------------------------
However, this solution is not really recommended if you're not
familiar with the internals. I'm not going to debug you through those,
You'd have to do that yourself... You'll need some time to get it
right. For now, I'd prefer the plain SQL hack:
// ------------------------------------
create.select().from(MY_TABLE).where(condition).and("1 = 1 FOR UPDATE");
// ------------------------------------
Another option: You could wrap that code in a stored procedure? jOOQ
also generates source code for those.
For now, I'd prefer the plain SQL hack:
// ------------------------------------
create.select().from(MY_TABLE).where(condition).and("1 = 1 FOR UPDATE");
// ------------------------------------
Use Factory.plainSQLCondition() to construct such conditions.
Cheers
Lukas
Thank you. I'm glad the "overall package" is well received. Think
about that, when I go closed source and 500$ per license ;-) just
kidding.
But you could do me a favor and blog about jOOQ in Russia. The more
users I get the more focused to real needs my developments will be.
Cheers
Lukas
Thank you
> Hope Maven central offers some kind of download statistics for packages?
Yes, but they're updated only once a month. So I don't have any
statistics yet. These are good too, though:
http://sourceforge.net/downloads/jooq/stats_timeline
I haven't tried anymore. I don't know what that SVN import does. It
takes forever and then crashes. I'll try exporting from SVN into a new
Eclipse workspace, and then sharing it freshly on GitHub. I guess the
SVN history is not very important if I'm using Git as a secondary
version control system? I'll find a way eventually...
You win. I'll try that
Что такое IntelliJ IDEA и что она может? Проще сказать что она не может. Она не умеет варить кофе (только косвенно, через IDE Talk). В силу этого сравнение ее с Flex Builder равносильно сравнению возможностей пешехода с гоночной машиной в контексте прохождения дистанции на скорость. Даже если вы придете домой пьяный, Диана вас накормит и не будет возмущаться, что вы какой-то сторонний файл не принадлежащий ни к одному из проектов, а безропотно сделает все, что в ее силах из того, что делала когда вы были чистый и трезвый. Она и в самом деле весьма интеллектуальна.
What is IntelliJ IDEA and what can she do? It's easier to say what she can't. It can't make a good coffee (only indirectly, using IDE Talk). And because of this comparing her with Flex Builder is like comparing pedestrian with a sport racing car. If you ever come home drunk, Diana will feed you and will never complain that you are some alien file and not from her project at all. She will do whatever she can for you pretending you are clean and sober. She is really very intellectual.
With the existing workaround possibilities, yes. The last thing you
could try is to make nested selects. I don't know if MySQL will like
that. But you could have the inner select apply the LIMIT and the
outer select apply the FOR UPDATE. Or vice versa. If that doesn't work
and if this is urgent, I recommend patching
AbstractResultProviderSelectQuery.toSQLReference() for this. That's
the single central place, where a SELECT statement's SQL is created...
Apart from other things, it now includes a fix for
https://sourceforge.net/apps/trac/jooq/ticket/420
Cheers
Lukas
No, that's why I pointed you to the sonatype repository. Maven central
doesn't accept snapshot deployments...
It's understandable, too. Once an artefact's version "goes central",
it will be published forever. On the other hand, the Sonatype
repository may be subject to change (both the Sonatype URL's *and* my
choice to actually use Sonatype).
So I'm guessing, in order to get latest releases AND snapshots, you'll
have to manually set up the Sonatype repository in your workspace, for
now.
Check again:
http://jooq.svn.sourceforge.net/viewvc/jooq/jOOQ/src/main/java/org/jooq/LockProvider.java?view=markup