Hi Joachim, Thanks for sharing your thoughts.
>> Any other opinions on this subject? > > It can break all kinds of assumptions if modifying the PK is allowed. Yes. Modifying PK values is very bad practice. This is independent of jOOQ, JDBC, Java, and any other database access layer. It is bad from a relational perspective. > People tend to use PK->Entity HashMaps when dealing with large-ish quantifies > of records. These will break as soon as the PK is modified. > This is not a problem as long as the programmer that does the PK update also > does the HashMap, but sometimes entities get passed around and kept track of > behind the scenes, and those behind-the-scenes mechanisms will break. Quite right. Once a PK is changed, all sorts of dependent objects need to be updated. > That said, I think there should be a way to update PKs, but it should be > clearly marked as dangerous. Whether that's a big fat warning in store's > javadoc, or a special updateThePk function, or anything else, I can't say. Good idea. If store() is changed, its Javadocs will contain such a warning. Nevertheless, just avoiding PK changes and instead performing Record copying might be even more weird to some users. If some client code changes a PK value by accident (i.e. through a bug), then running an INSERT is about as bad as "accidentally" updating the PK. > 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 Cheers Lukas
