Hi Marco, On Jan 2, 2008, at 11:03 AM, Marco Schulze wrote:
Craig L Russell wrote:This might be an academic discussion. But what fun. ;-) The main reason for jdoMakeDirty is to mark fields that cannot markthemselves as dirty; that is array types that by implementation cannotbe extended or enhanced. If an array type field has a non-null value that needs to be marked dirty, then the field is loaded. And if the value is loaded, jdoMakeDirty won't throw an exception.For consistency, though, I'd have to vote for jdoMakeDirty throwing anexception on an unloaded field. CraigHello Craig, first, I'd like to agree that throwing an exception is the better choice, since it provides additional information (was the fieldpresent?) and applications can choose to catch it, if they want to haveit ignored.
Right.
Additionally, I'd like to mention that we need it in a multi-datastore environment (i.e. replication) and therefore want to use it for allfields (not only arrays). Otherwise existing records in the destinationdatastore wouldn't be updated (since no field was changed between detaching attaching).
Right. There is no good alternative to marking fields as dirty because reflective access also bypasses the get/set methods.
Please allow me to bring up my feature request for this replication usecase again:Every datastore should have a unique identifier and a detached object should know from which datastore it has been detached. Hence, when attaching it, the JDOimplementation could check whether the datastore is the same and if itis not, treat every field as dirty.This datastore-identifier should be an optional feature, of course, since many people work with solely one datastore.
For now, your workaround will have to suffice. Best, Craig
Best regards, Marco :-)
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
