Hi, Right now, I don't see strong use cases where it is interesting to store "more" than the UUID with BeanReferenceCollectionConverterImpl & ReferenceBeanConverterImpl. Is it not possible to have 2 steps : 1/ create the referenceable object 2/ add the reference into another object ? If not, keep your converter and we will see if others want to have the same requirement. It is too early to modify thoses converters. I would like to wait. You can also add a new Jira issue. By this way, others can vote on it.
br, Christophe On 8/16/07, Padraic Hannon <[EMAIL PROTECTED]> wrote: > > We are using the repository pattern for our object retrieval > (http://www.martinfowler.com/eaaCatalog/repository.html) and I am trying > to migrate from a typical ORM system (toplink, hibernate, etc) backed by > an RDBMS to jackrabbit (actually CRX) using the jcr-mapping project. > > It appears that for child object the jcr project does what I would > assume (NTCollectionConverterImpl) and stores the objects that haven't > already been stored. However, if one does not one a referenced object to > be a child but rather just a property with a reference then things start > to diverge from what I would assume would happen. Perhaps, the error is > in my modeling (entirely possible!), however, I would think that the > Reference converters for both beans and collections would do more than > just persist the UUIDs. Would it be horrible if these where updated to > persist the referenced object is a UUID is not present prior to > persisting the referenced object? Of course I think it should probably > update the referenced objects properties if the object already exists. > Does this make sense? It adds complexity, but it seems like that would > be the expected functionality. > > -paddy >
