Dear JDO Expert Group,
may we kindly request an extension of the JDO spec: Additionally to
"fetch-depth", there should be a "recursion-depth" declarable per field
within a fetch-group.
I'd like to explain what I mean with a little use-case:
Imagine, we've got the following classes:
class City {
List<Factory> factories;
List<Shop> shops;
}
class Factory {
City city;
List<Car> cars;
}
class Car {
List<Factory> factories;
List<Shop> shops;
}
class Shop {
City city;
List <Car> cars;
}
...and we're using an EJB (or whatever backend-object) with the
following methods:
Factory getFactory(FactoryID id, String[] fetchGroups);
Car getCar(CarID id, String[] fetchGroups);
Shop getShop(ShopID id, String[] fetchGroups);
Now, we first imagine, we have a "recursion-depth" available. This
"recursion-depth" is not counted relative to the absolute root of the
object graph (like the fetch-depth), but only when the same field of the
same class is recursively passed by the detach-process. In order to give
the client the maximal flexibility to get object graphs shaped in
whatever form he wants, we simply need the following fetch-groups:
* City.factories
* City.this
* Factory.city
* Factory.cars
* Factory.this (contains all fields)
* Car.factories
* Car.shops
* Car.this (contains all fields)
* Shop.city
* Shop.cars
* Shop.this (contains all fields)
All of these fetch-groups would be declared with fetch-depth=0 and
recursion-depth=1.
But then, let's assume we have no "recursion-depth" (as it is currently
the case) and only a "fetch-depth", which is counted relative to the
root of the object graph. In order to give the client the same
flexibility, we need many more fetch-groups:
Fetch Group | Fetch-Depth | Possible Object Graphs
-------------------------------|----------------------------------
City.factories_1 | 1 | City => Factory
------------------------------------------------------------------
City.factories_2 | 2 | Shop => City => Factory
| | Factory => City => Factory
------------------------------------------------------------------
City.factories_3 | 3 | Car => Factory => City => Factory
| | Car => Shop => City => Factory
------------------------------------------------------------------
City.shops_1 | 1 | City => Shop
------------------------------------------------------------------
City.shops_2 | 2 | Factory => City => Shop
| | Shop => City => Shop
------------------------------------------------------------------
City.shops_3 | 3 | Car => Factory => City => Shop
| | City => Factory => City => Shop
| | Car => Shop => City => Shop
| | City => Shop => City => Shop
------------------------------------------------------------------
Factory.city_1 | 1 | Factory => City
------------------------------------------------------------------
Factory.city_2 | 2 | City => Factory => City
| | Car => Factory => City
------------------------------------------------------------------
Factory.city_3 | 3 | Shop => City => Factory => City
| | Factory => City => Factory => City
| | Shop => Car => Factory => City
| | Factory => Car => Factory => City
------------------------------------------------------------------
MANY MANY MORE | |
I hope by this - still quite simple - use case, it becomes already
obvious, that the number of necessary fetch-groups explodes. We need for
every possible graph size one more fetch-group per field. This is really
a lot! The alternative would be to only define those fetch-groups that
are currently needed, but then the backend has to be changed whenever
the front-end needs different object graphs - and IMHO this would be bad
design.
I see the following possibilities:
* Add "recursion-depth" to the spec and have the detach-process stop
detaching whenever the first limit (fetch-depth or
recursion-depth) has been reached for a field.
* Make "fetch-depth" to what I named "recursion-depth" as can
already be understood from the current spec. Then it would of
course be necessary to add a maximum fetch-depth to either the
detachCopy method or to the fetch plan.
* Leave it as it is and force either the JDO user to declare many
fetch-groups (which is error-prone and unconvenient) or the JDO
implementation to offer a vendor-extension.
Thank you very much in advance for considering one of the first two
solutions.
Best regards,
Marco Schulze
NightLabs GmbH
