Hi Tony,
Here are the questions:
1. Should the fetch-depth="0" defined in the class->field work?
Both the field-defined fetch-depth and the group1-defined fetch-depth
are 0. So it's not clear what you mean.
It does not have any effect right now in JPOX, but again, the spec
does not say anything about how this should work. I have to define
a fetch-group, so I can use the fetch-depth feature.
No, you can use fetch-depth on a field. And you do in your example.
<!ATTLIST field fetch-depth CDATA #IMPLIED>
If you omit the fetch-group group1 from your example, the default
fetch group should fetch the parent(s) recursively.
What my assumption is "this is the default fetch-depth, which can
be overridden by field fetch-depth definition in individual
groups." Anyone have any idea?
Yes, the fetch-depth in the field definition can be overridden by the
fetch-depth in individual groups.
2. When I save the first child, the parent and grandparent are also
saved. Since all 3 objects were transient before the makePersistent
call, they should be in detached state as the spec 13.4.2 said.
Right. First they are made persistent by reachability and then they
are detached in place.
Now I changed the parent's name to David, and call makePersistent
on child2 having the same parent. Is this legal?
It is not legal according to the Proposed Final Draft, but it is
legal according to a change the expert group just approved. With the
change, attachCopyAll no longer exists and you use makePersistentAll
to attach objects or make transient objects persistent. So your usage
is correct here.
or should I call attachCopyAll instead? If it is legal, then what
should happen here? The spec has no definition what to expect to a
detached-dirty object referenced by the target object. Should JDO
save the parent's name?
Yes. Once JPOX code base has been updated to reflect the latest spec
change, attaching a dirty-detached object will affect the cache, and
the dirty object should be committed to the database as well as the
newly created child2.
3. What should be the object referenced by the parent field of
child2 after the save?
When you called makePersistentAll on child2, it became persistent and
a copy of its parent was put into the cache. And when you committed
the transaction, the instances in the cache were detached. So the
parent of child2 is a detached instance that has the new name and is
distinct from the original parent.
Note it is detach-all-on-commit. Should it be the original parent
instance, or a new detached-clean instance? If it is later case,
then the original detached parent instance become useless.
Well, it is still detached, it still has its version number and
state, but it's now stale (it can't realistically be used further),
and it's therefore not much use. If you are going to use instances
after the commit, they should be from the instance graph that was
most recently detached.
Would not be better to have an attach method let the PM manage the
instance, so we can get it back after the transaction is committed,
using detach-all-on-commit or a detach method?
This scenario only works if the cache never contains instances with
the same persistent object id as instances to be attached. And there
are issues with rollback of detached instances that are attached in
place.
4. What kind of instances should I got back from my listAll method?
detached-clean or hollow?
Regardless of whether the commented-out method is called, you will
get detached instances. The effect of the commented-out method is
that it creates a copy of the cached instances and detach-all-on-
commit doesn't create a copy but detaches in place.
According to my understanding of detach-all-on-commit, they should
be detached-clean, am I right? Do I need to call detachCopyAll to
get the detached instances?
There is no need to call detachCopyAll for this case.
Thank you for your help in advance!
You are welcome in arrears.
Craig
Tony
On Nov 28, 2005, at 6:52 AM, Tony Lai wrote:
Hi,
Since these questions are about the spec, I hope someone from the
expert group can give me the answers. This is also posted on
JDOCentral's forums http://www.jdocentral.com/forums/index.php?
s=37b48c123ee46e821f97901d00afaeeb&showtopic=1590.
First, let me define a couple simple classes for demo purpose.
CODE
public class Person implements DetachCallback {
private String name;
private Person parent;
public Person(String name) {
this(name, null);
}
public Person(String name, Person parent) {
this.name = name;
this.parent = parent;
}
...getters and setters...
public String toString() {
String parentStr = null;
try {
Person myParent = getParent();
if(myParent != null) {
parentStr = myParent.toString();
}
} catch(Exception x) {
//may be caused by field not loaded. Ignore it for now
}
return name +"["+System.identityHashCode(this)+"]"+
(parentStr == null ? "" : (" parent: " + parentStr));
}
public void jdoPreDetach() {}
public void jdoPostDetach(Object detached) {
System.out.println("jdoPostDetach: "+name);
}
}
public class DetachTest {
protected PersistenceManager pm;
Person grandParent = new Person("Bob");
Person parent = new Person("Dave", grandParent);
Person child1 = new Person("John", parent);
Person child2 = new Person("Mary", parent);
public DetachTest () {
pm = createPersistenceManager();
pm.setDetachAllOnCommit(true);
}
public void test() {
//This should save child1, parent, and grandParent.
makePersistent(child1);
System.out.println(child1);
// Now change the parent name
parent.setName("David");
makePersistent(child2);
System.out.println(child2);
System.out.println();
List list = listAll(Person.class, true, "group1");
for (Iterator i = list.iterator(); i.hasNext();) {
Object obj1 = i.next();
System.out.println(" item: "+obj1);
}
}
public static void main(String[] args) {
new DetachTest ().test();
}
public void makePersistent(Object obj) {
Transaction tx = pm.currentTransaction();
try {
tx.begin();
pm.makePersistent(obj);
tx.commit();
} finally {
rollbackIfActive(tx);
}
}
public List listAll(Class targetClass, String fetchGroup) {
Transaction tx = pm.currentTransaction();
Extent extent = null;
try {
tx.begin();
pm.getFetchPlan().setGroup(fetchGroup);
List data = new ArrayList();
extent = pm.getExtent(targetClass,false);
for (Iterator i = extent.iterator(); i.hasNext();) {
Object obj1 = i.next();
data.add(obj1);
}
//data = (List)pm.detachCopyAll(data); // see question 4
tx.commit();
return data;
} finally {
closeIterators(extent);
rollbackIfActive(tx);
}
}
... some helper methods...
}
<jdo>
<package name="test.jpox.detach">
<class name="Person" detachable="true">
<field name="parent" default-fetch-group="true" fetch-
depth="0"/>
<fetch-group name="group1">
<fetch-group name="default"/>
<field name="parent" fetch-depth="0"/>
</fetch-group>
</class>
</package>
</jdo>
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!
