Re: Make dirty of detached objects?

[Craig L Russell]

Here's the proposed spec change:

<proposed>
void jdoMakeDirty (String fieldName);
void jdoMakeDirty (int fieldNumber);
A7.2-1 [




</proposed>

On Jan 2, 2008, at 4:06 AM, Marco Schulze wrote:

These methods mark the specified field dirty so that its values will be modified in the datastore when the transaction in which the instance is modified is committed. The fieldName is the name of the field to be marked as dirty, optionally including the fully qualified package name and class name of the field]. A7.2-2 [This method returns with no effect if the instance is not detached or managed by a StateManager.] This method has the same effect on the life cycle state of the instance as changing a managed field would. The fieldNumber parameter is the internal field number assigned during class enhancement. If the instance is detached and the field has not been loaded, JDODetachedFieldAccessException is thrown.

Andy Jefferson wrote:

Therefore, I'd like to kindly ask for a spec change:
JDOHelper.makeDirty(...) and the corresponding

as well.

PersistenceCapable.jdoMakeDirty(...) should work with detached objects

+1 but
"JDOHelper.makeDirty(...) and the corresponding

the specified field is loaded in the detached object"

have a new value ;-)

PersistenceCapable.jdoMakeDirty(...) should work with detached objects where since if the field is not loaded it makes no sense to mark it as dirty yet not

I totally agree! Of course, makeDirty/jdoMakeDirty only makes sense
for fields that have been loaded in the detached object.

Will the method throw a javax.jdo.JDODetachedFieldAccessException
or silently ignore non-loaded fields in detached objects?

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature