You can actually add this code to your GenericRecord super class and add the column to all your tables on the fly, and defaulting the column to NULL if 3rd party applications are inserting into the database. If 3rd party apps are updating other columns live, then you''ll have to keep those as locked columns anyway though.
public void validateForSave() throws NSValidation.ValidationException ()
if (dateLastUpdated()==null) setDateLastUpdated(new NSTimestamp());
... do rest of validation...
}
I believe that the above code will update dateLastUpdated in EOs with no actual changes. Any EO in which an attribute or to-one relationship has been set will be marked as updated even when the new values are identical to the old values. No SQL would be generated normally, but because you have actually updated dateLastUpdated, the database will be needlessly updated.
To make this work correctly can be tricky and can depend on whether you are viewing this from the point of view of attributes and relationships or columns and foreign keys.
You need to examine updatedObject.changesFromSnapshot(editingContext.committedSnapshotForObject(updatedObject)). If this is an empty dictionary, no actual changes have occurred, so dateLastUpdated shouldn't be updated.
If a to-one relationship value has actually changed, then updatedObject's foreign key value has also changed, so dateLastUpdated should be updated.
However, if only a to-many relationship array has changed, no SQL update statement for updatedObject will be generated because only foreign keys in relationship destination objects have been updated, so updatedObject.dateLastUpdated shouldn't be updated. Others may consider updatedObject to be updated because one of its to-many relationships has been updated, so in this case, updatedObject.dateLastUpdated should be updated. I take the former point of view.