>> One data point from the outside: Hibernate is using a cache of >> load-time field values as the basis for a considerable fraction >> of its services, and the keys are PK values. If you modify a PK, >> Hibernate will fail, crash and burn, and very quickly. > > I feel that the whole database should fail, crash and burn
Hehe, I sympathize with that sentiment. If databases made PKs read-only, we'd also finally have an easily explainable difference between PKs (read-only) and unique keys (updatable). That's not gonna happen I guess *dreams*. A general observation: altering a PK is like renaming something. For some kinds of records, the name is the identity; for others, name and identity can be seen as independent. (Using a separate artificial numeric id is then the "real identity" if you will.) Allowing PK changes is definitely going to kill optimistic locking. You don't even have a clearcut idea what "the same record" even means in that context: If another process changes the PK to yet another value, should that be considered a copy or a conflicting update? I guess the answer depends on the situation, which means that JOOQ would need to be told which one is right. Meaning "more API", which is a downside. 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. 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 ;-)
