> If databases made PKs read-only, we'd also finally have an easily explainable > difference between PKs (read-only) and unique keys (updatable).
Yes, that would be quite useful. I don't see any other reason to distinguish PKs and UKs. > PK changes start to get a stable semantics if the record is locked on SELECT. > Then the identity of the records won't change while you're busy updating the > PK. > Maybe that's the way to go: Allow PK updates if and only if the object came > by means of SELECT ... FOR UPDATE or some other means of locking. Of course, > that's not optimistic locking anymore, but I don't think the whole concept is > very useful in a PK-modifying situation. Precisely. You should pessimistically lock the row when your intent is changing the PK. And you should lock it as early as possible. Some more interesting insight on the topic: http://stackoverflow.com/a/3838649/521799 > Disclaimer: > I'm just tossing around ideas based on general DB experience, recent > Hibernate experience, and a very thin varnish of JOOQ knowledge from reading > the docs. Once. Diagonally. > IOW just tell me as soon as I'm starting to go off on a tangent that's > irrelevant to JOOQ, so I'll shut up before making a complete fool of myself > ;-) No worries. These things are not off-topic on this user group. Cheers Lukas
