Re: [IMPORTANT] Fetch-depth

[Craig L Russell]

Hi Alexander, On Jan 16, 2006, at 7:53 AM, Alexander Bieber wrote: Thanks Craig for taking our arguments into account. I'll still have a comment concerning the use case Jörg von Frantzuis submitted. His case is to limit the object-plan depth to a certain level while using FetchPlan.ALL as fetch-group. This is used for synchronizing data between datastores generically. In my oppinion we should think of an additional and optional (defaulting to -1) parameter to detachCopy - detachDepth - for this case. The issue I have with this is that if you have a collection of items that you can reliably use to transfer from one datastore to another, then there is a natural graph that describes it without arbitrarily cutting off connected instances by use of the fetch-depth, whether by field or by API. Said in another way, if you really want to transfer a collection of items from one datastore to another, it should be possible to come up with a fetch plan that accomplishes this. Especially considering that for relational datastores, the bidirectional relationship between two instances is usually instantiated only one side in the datastore, and for non-relational datastores, not instantiating a relationship on both sides would cause data corruption. Warm regards, Craig Best regards Alexander Bieber Craig L Russell wrote: Javadogs, I've spent some time looking at the semantics of fetch-depth and now agree with the critics of the change that I proposed back in the infamous October 1, 2005 message to the expert group subject: *Re: JDO2 §12.7.2: fetch-depth only for "recursive fetch group references"?*. I now believe it's impractical to use fetch-depth to mean the maximum depth of the object graph reachable from the root object(s) field because of several messages sent on the subject by Joerg von Frantzuis, Alexander Bieber, and Marco Schultz. Briefly, the argument is that if fetch-depth limits the number absolutely, then it's not possible easily to use the fetch-group to add another field to a fetch plan simply by adding a fetch-group that includes that field. Instead, a new fetch-group that changes the fetch-depth must be used. And each new use-case needs to provide a different fetch-depth number if another level of fetching is desired. I believe that the use of fetch-group to determine whether fields (navigating relationships) are fetched should be natural, and that we should therefore use fetch-depth for its original purpose of limiting recursion. If you disagree with this position, please reply so we can move forward and define the use of fetch-depth for recursion (as in the original semantics of the attribute). Thanks, Craig 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! 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!

smime.p7s
Description: S/MIME cryptographic signature