I have been trying to hunt down why attempts to set a field on a database row object have been ignored, and have uncovered why.
What I have is a table that is updated inside a transaction. First, a certain set of date rows in the table are set to null. Then, a second set of date rows are set to non null values - these two sets may intersect, and the dates may possibly be set to the same values they held at the start of the transaction.
The set field generated code for a date looks like this:
/**
* Set the value of PostedDate
*/
public void setPostedDate(Date v )
{
if (!ObjectUtils.equals(this.postedDate, v)) {
this.postedDate = v;
setModified(true);
}
}The first time the set field is called, this.postedDate is a Date, and v is null, so this.postedDate is set to v and setModified is made true. A save method is subsequently called - but as the transaction is not complete, the date is not immediately accessible.
The second time the set field is called, this.postedDate is a Date -> the original date *before* the start of the transaction, and not null. In this particular example, the Date is also *identical* to it's previous value. In this case, this.postedDate equals v, and the update is *not* run.
The transaction is completed, the database write happens, but as the second set field was ignored, the date field becomes what it was set to in the first set field - null - which is incorrect.
The fix seems to be to remove the ObjectUtils.equals() function, or to at least disable it while a transaction is in progress.
Is this the solution, or have I missed something?
Regards, Graham --
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
