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.
You could just throw an exception on PK update.
In my case, I can use a system generated PK and then set my current PK
as unique field instead. I have no records linking to this table. So it
would just mean redundant data in my case which is also violating
relational database principles :)... well not really redundant, but a
useless field just for the purpose of not changing the primary key.
In any case I don't think JOOQ should stop a user updating the PK. If
they want to then they can sort out their own mess later.
Let's talk about updating a composite primary key! :)
