jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christophe Lombart" <christophe.lomb...@gmail.com>
Subject Re: jcr mapping question
Date Thu, 16 Aug 2007 08:21:10 GMT

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.


On 8/16/07, Padraic Hannon <pih@wasabicowboy.com> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message