|
Home > Archive > Apache JDO Project > January 2008 > Make dirty of detached objects?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Make dirty of detached objects?
|
|
| Marco Schulze 2007-12-29, 7:11 pm |
| Hello *,
I've a problem with replicating JDO objects from one datastore to another.
I detach the object from datastore A and attach it to datastore B. Since
no field was changed, the data in datastore B is not updated.
So I wanted to use JDOHelper.makeDirty(...), but unfortunately, it doesn't
show any effect. Hence, I read in the spec about "make dirty" and saw that
chapter 7.2 (page 77) states:
"This method returns with no effect if the instance is not managed by a
StateManager."
This makes sense for real transient objects, but IMHO not for detached
ones, because:
1st: Detached objects are able to track changes just like persistent
objects are. So it should technically be no problem to provide API
(=> JDOHelper.makeDirty(...)) for making a field dirty.
2nd: The "array problem", for which the "makeDirty(...)" method has been
created (if I understand the reasoning correctly) exists with detached
objects as well. It is therefore intuitive that the solution for the
"array problem" is the same for detached as for persistent objects.
Therefore, I'd like to kindly ask for a spec change:
JDOHelper.makeDirty(...) and the corresponding
PersistenceCapable.jdoMakeDirty(...) should work with detached objects
as well.
Additionally, I'd like to suggest a new feature: 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.
And finally, I'd like to know why there is only
JDOHelper.isDirty(Object), but no way to find out which field it is.
This is currently not important to me, but I'd find it more
straight-forward, if makeDirty and isDirty were corresponding (i.e.
provided the same granularity).
Best regards and a HAPPY NEW YEAR!!!
Marco Schulze
JFire.org
NightLabs GmbH
| |
| Andy Jefferson 2008-01-01, 7:11 am |
| > Therefore, I'd like to kindly ask for a spec change:
> JDOHelper.makeDirty(...) and the corresponding
> PersistenceCapable.jdoMakeDirty(...) should work with detached objects
> as well.
+1 but
"JDOHelper.makeDirty(...) and the corresponding=20
PersistenceCapable.jdoMakeDirty(...) should work with detached objects wher=
e=20
the specified field is loaded in the detached object"
since if the field is not loaded it makes no sense to mark it as dirty yet =
not=20
have a new value ;-)
=2D-=20
Andy =C2=A0(Java Persistent Objects - http://www.jpox.org)
| |
| Marco Schulze 2008-01-02, 7:11 am |
| Andy Jefferson wrote:
>
> +1 but
> "JDOHelper.makeDirty(...) and the corresponding
> PersistenceCapable.jdoMakeDirty(...) should work with detached objects where
> the specified field is loaded in the detached object"
> since if the field is not loaded it makes no sense to mark it as dirty yet not
> have a new value ;-)
>
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?
| |
| Andy Jefferson 2008-01-02, 1:11 pm |
| > Will the method throw a javax.jdo. JDODetachedFieldAccessException
> or silently ignore non-loaded fields in detached objects?
I'd just expect a silent ignore.=20
The only place a JDODetachedFieldAccessException should be thrown is in any=
=20
actual access of the field (jdoGetXXX with persistent fields, or getXXX wit=
h=20
persistent properties)
=2D-=20
Andy =C2=A0(Java Persistent Objects - http://www.jpox.org)
| |
| Craig L Russell 2008-01-02, 1:11 pm |
| | |
| Craig L Russell 2008-01-02, 1:11 pm |
| | |
| Marco Schulze 2008-01-02, 1:11 pm |
| 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 :-)
| |
| Craig L Russell 2008-01-02, 7:11 pm |
| |
|
|
|
|