GetDetachedObjectId -vs- getObjectId

Question

I am trying to set the object ID of a detached instance. I find that there
is a difference in the return result between the following.
Assume that "obj" is a detached object.
KodoHelper.setDetachedObjectId(obj, stringValuedID );
KodoHelper.getDetachedObjectId( obj ) ......gives the set stringValuedID
JDOHelper.getObjectId( obj ) .......gives original object id.
How do ObjectId and DetachedObjectId relate to one another?
I want to explicitly manage the object id. Bottom line is that I am
working with multiple PMs each with their own database. I have shadow
instance objects located in each database ( same instance, but different
object id's ). If an object under one PM changes, I would like to update
the shadow instance with the changes. I was trying to use attach/detach
methods to accomplish this.
The logic would look like the following.....
1) Fetch and detach changed object under PM1.
2) Fetch and detach shadow object under PM2.
3) Set the detached object id of the changed object to that of the shadow
object.
4) Perform an attach call using PM2 on the changed object that now has the
shadow object's id.
.....I expect the PM to think that my original detached shadow
object has simply been changed and now the PM will go through the usual
attach process and perform updates to fields that have been modified.
The problem with the above is that when attaching, the PM seems to still be
looking at the ObjectID ...not the DetachedObjectID. So, PM2 complains that
my changed object still belongs to PM1 and will not let me attach.
Thanks in advance for advice.
-Robert

Answer 1

Robert-
You are correct that a detached instance is not associated in any way
with any PersistenceManager.
You are also correct that the get/setDetachedObjectId methods are used
by the KodoPersistenceManager to identify the object when it is
re-attached. If the object id field is null or if it cannot construct an
ID from it, then Kodo will assume that the instance is a new instance,
and will treat it as such. It sounds like this is what is happening.
If might be easier for you to make a custom field to hold the detached
object id, using the "detached-objectid-field" metadata extension, in
which case you will be able to access that field at any time (note that
the field needs to be unmanaged).
Let us know if you still have the same problem. Any stack traces that
you see would be useful in determining the exact cause of the problem.
In article <[email protected]>, Robert Greene wrote:
To answer my own question ......kodo does not track any association with the
PM once detach is called. My problem was that I was not using the copy
created by the detach call ....but instead I was returning the actual
database object :-(
The above being said, still when I attempt to perform the logic defined
below it fails when I try to reattach. Somehow it is assigning a new OID to
the object on attachment and then it cannot find an object with this OID in
the database. I am still looking into this.
I am interested in feedback about the intended use of setDetachedObjectId.
I think that what I am trying to do should be possible, but I am making the
assumption that the attach methods implementation would get the value of the
DetachedObjectId, try and locate the original object with that
DetachedObjectId in the database ( getObjectById ) and then update the
database object's fields with the values found in the detached object.
-Robert
"Robert Greene" <[email protected]> wrote in message
news:[email protected]...
Thanks Patrick,
How does kodo track a detached object's association with a PM? I wasunder
the assumption that once detach is called, there is no longer any
association with a PM. When an object is detached, is there still some
other loose coupling with the originating PM? What would be the reasons
that the attachment processes would complain about a detached object still
being associated with another PM?
Do you see anything wrong with the logic of how I am attempting to use
attach/detach? I know that it is not the intended use, but I think that
theorectically is should work. There is really no documentation aboutthe
intended use of KodoHelper.setDetachedObjectId. Am I using it correctly
....that is .....should I expect the attachment process to use the new
ObjectId? If not, what is the intended use of the setDetachedObjectId
method?
Many thanks,
-Robert
"Patrick Linskey" <[email protected]> wrote in message
news:[email protected]...
Robert,
The detached OID and the OID itself are separately managed -- an object
has either one or the other, depending on whether or not it's detached.
So, setting the detached OID doesn't set the OID. Instead, the
attachment process does the appropriate work to get the OID into the
right state.
-Patrick
Robert Greene wrote:
I have found in the doc that getObjectId is returning and instance of
kodo.util.Id where getDetachedObjectId is returning a String
...representing
the ObjectId ....so I see the difference in the methods. I suppose
this
makes it easier for serializing the object and sending it around. SoI
guess the question is, why does setDetachedObjectId only set theStringified
value and not in addition, the actual object id that it is associatedwith?
Then the next question, how do I set that object id?
Thanks,
-Robert
"Robert Greene" <[email protected]> wrote in message
news:[email protected]...
I am trying to set the object ID of a detached instance. I find thatthere
is a difference in the return result between the following.
Assume that "obj" is a detached object.
KodoHelper.setDetachedObjectId(obj, stringValuedID );
KodoHelper.getDetachedObjectId( obj ) ......gives the set
stringValuedID
JDOHelper.getObjectId( obj ) .......gives original object id.
How do ObjectId and DetachedObjectId relate to one another?
I want to explicitly manage the object id. Bottom line is that I am
working with multiple PMs each with their own database. I have shadow
instance objects located in each database ( same instance, butdifferent
object id's ). If an object under one PM changes, I would like toupdate
the shadow instance with the changes. I was trying to use
attach/detach
methods to accomplish this.
The logic would look like the following.....
1) Fetch and detach changed object under PM1.
2) Fetch and detach shadow object under PM2.
3) Set the detached object id of the changed object to that of theshadow
object.
4) Perform an attach call using PM2 on the changed object that now hasthe
shadow object's id.
.....I expect the PM to think that my original detached shadow
object has simply been changed and now the PM will go through the
usual
attach process and perform updates to fields that have been modified.
The problem with the above is that when attaching, the PM seems tostill
be
looking at the ObjectID ...not the DetachedObjectID. So, PM2 complainsthat
my changed object still belongs to PM1 and will not let me attach.
Thanks in advance for advice.
-Robert
Marc Prud'hommeaux [email protected]
SolarMetric Inc. http://www.solarmetric.com