Hi Sascha, UpdatableRecords have a "history" in jOOQ, which may not seem obvious at first. Most of what may appear odd is based on an initial design assumption that you're working on a normalised database schema, which means that you do not change primary key values.
I will add further comments inline. 2014-09-24 19:49 GMT+02:00 Sascha Herrmann <[email protected]>: > Hi! > > I have a question regarding updating and inserting. > > The AbstractRecord class marks every field as changed for which a > setValue() was invoked. Only for key fields an equals() check is performed? > I wonder why that is. > If you do change a record's primary key values (remember the above assumption of not changing those values), the existing jOOQ logic assumes that you wanted to create a copy of that record. So, setValue() on primary keys is in fact convenience for copying the record for insertion. Today, this logic may seem overly clever. For backwards-compatibility reasons, it's still there. The equals() check that you're seeing is also part of this backwards-compatibility. We're aiming at cleaning up this behaviour in jOOQ 4.0, by removing unnecessary "features". Today, this behaviour can be overridden via the "updatablePrimaryKey" Setting, though, as other customers have also been wondering about this legacy. > If I call a setter and the new value is equal to the value read as > original from the database, then the record in fact hasn't changed and an > update is unnecessary, no? > That depends on the semantics of such a value change. The original design required a means to *enforce* an update of a value. For instance to encourage reuse of statement plans in Oracle by avoiding unnecessary hard-parses. Or, to differentiate between "NULL" and "DEFAULT" when inserting / updating (record.setValue(field, null) should enforce setting of NULL). Note that the changed() flag manipulation API and the original() value access API have been added only much later. We do recognise, however, that the status quo has been a common source of confusion, and is thus not optimal. > We're doing synchronization work, and it would be very easy to just push > the new values into the original record read from database, and then call > changed() to see if it has actually changed or just call update() and let > jOOQ decide whether to update or not. The setValue() method would be such a > nice and central point to handle this, instead of iterating over the values > and comparing them "manually". > Yes, I agree. > Secondly, we run into a NullPointerException. > I will respond to that in a separate, new thread. It will be easier to track the different discussions. Regards, Lukas -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
