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. 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). 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. Best regards, Marco :-)
