Menu
▾
▴
#270 <check-dirty-after-get>
A <cmp-field> in jbosscmp-jdbc.xml has got an optional
<check-dirty-after-get> element which can contain true
or false.
<cmp-field>
<field-name>myCMPField</field-name>
<check-dirty-after-get>true</check-dirty-after-get>
</cmp-field>
If field's type is mutable and its value can be changed
without invoking its setter, e.g.
myBean.getMyCMPField().setValue(), the field should
have check-dirty-after-get set to true.
Value true means that the field will be checked for
dirty state at synchronization time even if only the
getter was invoked in a transaction.
By default, check-dirty-after-get is set to false only
for primitive, its wrapper and java.lang.String types.
WARN: if the BLOB type is immutable the
check-dirty-after-get should be false.
Logged In: YES
user_id=928242
Should the default be check-dirty-after-get=false for
java.math.BigDecimal, java.sql.Date, java.sql.Time,
java.sql.Timestamp and java.util.Date?
The default, check-dirty-after-get=false, for _only_
primitives, wrapped primitives and java.lang.String creates
updates after selecting rows that have columns with the
types listed above. I observed the SELECT/UPDATE behavior
in V3.2.3 when perfoming findByPrimaryKey() on a row with
java.math.BigDecimal (DECIMAL) and java.sql.Date (DATE).
The databases used were Pointbase and Informix.
Logged In: YES
user_id=543482
Yes for BigDecimal, as it is immutable. No for Date/time
classes as they are mutable.
Logged In: YES
user_id=988600
Why does JDBCTypeFactory default to CMPFieldStateFactory
INVALID_UNLESS_NULL? Can the equals() method not be
trusted for mutable field types?
Logged In: YES
user_id=543482
No, it can't. See
http://sourceforge.net/tracker/?func=detail&aid=850919&group_id=22866&atid=381174