Here are some comments on aggragations, references, ... :
1/ The REFERRENCE feature is not yet supported in the OCM frameworks. I think only a new BeanConcerverter impl is required (or maybe almost nothing). Any kind of contribution is welcome. 2/ For aggragation defined in the subnodes, it is possible to use the proxy features to maximize performance. As you certainly know, the beanConverter and CollectionConverter are there to retrieve, update, delete some aggregated objects. You can also disable some actions on aggragations (retrieve, insert/update, delete) with the attribtures "auto-*). 3/ There are a BeanConverter impl which gives the Parent Object (of course based on the Parent node). See the class ParentBeanConverterImpl. There is a small unit test. Kind regards, Christophe On 9/4/06, Dan Connelly <[EMAIL PROTECTED]> wrote:
Alex: I see that the JCR spec uses the term "Multiple Parents" for roughly the same concept as aggregation. Maybe the problem I am having is somehow due to the fact that the "hard links" support for Multiple Parents, method addExistingNode(String absPath) in the javax.jcr.Node interface, was dropped from the API (although the spec continues to describe it). The on-line discussion I am finding concerning nodes with "Multiple Parents" says that soft links using a REFERENCE property (or collection element) in all but one parent node is a reasonable substitute for aggregation.. The child's jcr node type must have mix:referenceable supertype. The soft link solution is okay with me, but I see no support for even that in the Graffito jcr mappings. Am I wrong?
What did you mean by a "custom bean discriptor"? I am open to any OCM solution but I do not see any features in bean-discriptor that cover REFERENCE as a jcrType. It is possible that I could use a hack by mapping a bean property as a field-descriptor and then suppling a custom object converter to insert a REFERENCE value in the field's jcr property. That custom object converter class needs to accommodate any bean class (for my requirements). This is non-trivial. Also, shared beans are not just bean fields. They might be elements in a collection. The single field-descriptor hack does not work in that case. There is no jcrNodeType in the collection-descriptor that would force the collection elements to be mapped as REFERENCE value nodes. -- Dan Alexandru Popescu wrote: > On 9/3/06, Dan Connelly <[EMAIL PROTECTED]> wrote: > >> How do you express aggregated, not contained, bean references in the >> OCM? >> >> An aggregate bean ref would (presumably) get persisted as a uuid uri, >> not as a content sub-node. (Path references might be okay instead of >> uuids.) >> >> If I map naively with two classes that where each has the other as a >> bean element, then pm.insert(rootObj) will traverse this loop >> endlessly. The rootObj class has proper containment of both these >> mutually referencing classes. >> > > I think you should use a custom bean descriptor to take care of this > kind of mapping. > > ./alex > -- > .w( the_mindstorm )p. > >> -- Dan >> >
-- Best regards, Christophe