> Any other opinions on this subject? It can break all kinds of assumptions if modifying the PK is allowed.
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. 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. 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. This in itself isn't necessarily relevant to JOOQ, but it's building programmer expectations, and also something that you need to explain to people coming from Hibernate to JOOQ. (I don't know how other ORMs handle the issue, but I wouldn't be surprised if they did the same.)
