-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Craig L Russell wrote: > 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 mark >>> themselves as dirty; that is array types that by implementation cannot >>> be 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 an >>> exception on an unloaded field. >>> >>> Craig >> >> Hello Craig, >> >> first, I'd like to agree that throwing an exception is the better >> choice, since it provides additional information (was the field >> present?) and applications can choose to catch it, if they want to have >> it 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 all >> fields (not only arrays). Otherwise existing records in the destination >> datastore 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 use >> case 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 JDO >>> implementation could check whether the datastore is the same and if it >>> is 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!
Hello Craig, thanks a lot for your response and sorry for my late reaction. I'm happy that you agreed on the first points and I can live just fine with "makeDirty" as a workaround for replication. The datastore-id was just a suggestion and I'm sure there will be more JDO releases in the future ;-) Best regards, Marco :-) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHj3wAOn48nLzkjcIRAiDnAJ9ueV4tyVxv+DfLuBHGc8ET1aaPcwCgh2eu QCZ8sFPZX6F4tcgF1SBv6lI= =DJCJ -----END PGP SIGNATURE-----
