Support optimistic locking via JPA

[AlecKazakova]

see https://www.baeldung.com/jpa-optimistic-locking

or maybe not via JPA, but this seems important!

[cgruber]

Any inclinations about this. This is definitely a show-stopper for one of our use-cases.

[AlecKazakova]

yes but it wont be anything where we write SQL for you, so you'll still have to write

UPDATE blah
SET foo = bar
WHERE version = 3;

and if you omit the version part we will fail the build, and maybe show an intention action on the query like "this needs an optimistic lock" and then you option+enter and it just adds it for you.

[AlecKazakova]

I'm open to other ideas though, and this is something I intend to have in the 2.0 release

[cgruber]

That seems pretty reasonable, as a way to offer the functionality. I could see some universe where we all had more time, where you could annotate a version field or something, or annotate an opt-lock constraint (just write the where clause) but as long as you CAN do this, and as long as the build fails if you miss it, I can see it being workable.

[AlecKazakova]

👍 i'll aim for that for next release since I think its pretty straightforward

[cgruber]

We're looking at evaluating using sqldelight in some hibernate cases, and this one is going ot be pretty important. I'm not clear on your timeline for 2.0 or whichever "next release" you are thinking of. Any (non-binding) notion of a timeline? I'd hate to end up on Jooq merely because of a disqualifying missing feature.

[AlecKazakova]

Not concretely, I'm hoping march. However I've been doing internal releases for Cash, I can just publish another one once this feature is done which would be a much shorter timeframe (like 2 weeks?)

[cgruber]

That would be dope. 🙏🏼