ignoring columns for update detection

[sfisque]

i have a set of entities that have two "meta data" columns, namely, "editor" and "updated" which are a UID and a date.

we are processing import files and persisting/merging the data that comes in. what i need, if it is possible, is a way to configure JPA (or hibernate directly) to ignore the "editor" and "updated" fields when the call to "merge" is done, so that if the entity is identical to what the database has, it discards the merge, even if the editor and updated are newer, because the relevant data is not updated.

example:

i have a bean with a first_name, last_name attribute, editor, and updated. the first_name and last_name attributes are identical to the database, but the editor and updated fields correspond to the process that is requesting the update. is there a way via configuration, annotation, or callback, to have hibernate ignore the updated and editor attributes when trying to detect if it needs to do an update or not?

TIA

== stanton

[sfisque]

how would one go about suggesting an enhancement to Hibernate (or JPA) to include a new annotation like @NotSignificant that would allow a developer to tag an attribute, similar to @Transient, so that the attribute would be persisted and retrieved "normally" but ignored for detecting "dirtiness" of an entity when deciding if it should be persisted to the database?

== stanton

[jaikiran]

There's a "updatable" attribute which you can set to false on the @Column annotation http://www.oracle.com/technology/products/ias/toplink/jpa/resources/toplink-jpa-annotations.html#Column

[sfisque]

except i want hibernate to update these columns.

the trick is to have hibernate send and receive the target columns to/from the database when doing an UPDATE, but when it is asked to merge the pojo, ignore them for deciding if the updated object is "dirty".

for the near term, i'm doing a brute force through the other attributes in a helper class "isDirty" method, but this ends up turning an O(n) test into O(2n) since hibernate is ALSO going to do this when it needs to decide if the underlying object is dirty before it commits the transaction.

the issue isnt "updatability" but "significance". in my case, the editor and updated are necessary to tag an update but are not considered "significant" with regard to object "dirtiness".

/sigh

== stanton