You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Michael Aemisegger <de...@pagnolia.ch> on 2005/06/13 23:21:31 UTC
Maintaining reference relations between repositories
Dear list
Suppose two repositories, an author and a public repository. You can activate
content from one to the other. The two repositories are physically separated,
maybe located on different machines.
My use case are references to nodes (e.g. links to a page or an asset) that are
of subtype mix:referenceable. The challenge we encounter is that the read only
property 'jcr:uuid' is generated automatically while activating and thus
references are lost.
How can you ensure that references in the author repository are respected in
the public repository?
Cheers,
Michael
Re: Maintaining reference relations between repositories
Posted by Michael Aemisegger <de...@pagnolia.ch>.
David Nuescheler wrote:
> the spec mandates the system view and the document view as
> your quote from the spec shows. i don't know why you think
> that the spec does not mandate the system view?
> it does by no means says "either or" it says "and" in your quote.
> the system view is also tested in the tck, so it is pretty safe to say
> that a compliant repository can deal with a system view.
ok, I realize my knowledge about the english language is not reliable enough. I
misunderstood it.
Thanks for your clarifications.
--
Cheers,
Michael
Re: Maintaining reference relations between repositories
Posted by David Nuescheler <da...@gmail.com>.
hi michael,
> This is one option we could imagine to go for. I simply wanted to ask for
> proven solutions with the use case in mind. Reading '7.3.2.1 Roundtripping', I
> can see what you mean.
> We are a bit worried to introduce dependencies on a specific repository
> implementation. Reading chapter 7.2 "Level 2 repositories must support the
> import of content from either of the standard XML mappings, system view and
> document view [...]" makes me think that for level 2 repositories import/export
> is supported. But only the system view garantuees completeness and allows for
> roundtripping. Since the spec doesn't force level 2 repositories to supply a
> system view (either system view or document view), we might run into difficulties.
the spec mandates the system view and the document view as
your quote from the spec shows. i don't know why you think
that the spec does not mandate the system view?
it does by no means says "either or" it says "and" in your quote.
the system view is also tested in the tck, so it is pretty safe to say
that a compliant repository can deal with a system view.
> Am I missing something or is my argument just practically irrelevant?
hmmm....
i recently stumbled over a few posts on the magnolia
dev-list, where people make scary statements with regards to
import and export being repository dependant...
let's say posts on the magnolia-dev list are with respect to jackrabbit /
jcr "generally unreliable" (to say it politely) and i would suggest
(just like you did now) to check with the jackrabbit-dev list if you need
an educated statement about a certain aspect of jcr or jackrabbit ;)
regards,
david
Re: Maintaining reference relations between repositories
Posted by Michael Aemisegger <de...@pagnolia.ch>.
Dear David
David Nuescheler wrote:
>>Suppose two repositories, an author and a public repository. You can activate
>>content from one to the other. The two repositories are physically separated,
>>maybe located on different machines.
>
> the term "activation" has no meaning in the realm of a content
> repository. since i know exactly where this term stems from,
> i think i understand that you talk about replication or syndication of
> content from one repository to the other.
That's exactly what I mean.
>>My use case are references to nodes (e.g. links to a page or an asset) that are
>>of subtype mix:referenceable. The challenge we encounter is that the read only
>>property 'jcr:uuid' is generated automatically while activating and thus
>>references are lost.
>>How can you ensure that references in the author repository are respected in
>>the public repository?
>
> export/import can keep the uuid's beyond the boundaries of a repository.
> it seems like the obvious solution to me... what did you have in mind?
This is one option we could imagine to go for. I simply wanted to ask for
proven solutions with the use case in mind. Reading '7.3.2.1 Roundtripping', I
can see what you mean.
We are a bit worried to introduce dependencies on a specific repository
implementation. Reading chapter 7.2 "Level 2 repositories must support the
import of content from either of the standard XML mappings, system view and
document view [...]" makes me think that for level 2 repositories import/export
is supported. But only the system view garantuees completeness and allows for
roundtripping. Since the spec doesn't force level 2 repositories to supply a
system view (either system view or document view), we might run into difficulties.
Am I missing something or is my argument just practically irrelevant?
--
Cheers,
Michael
Re: Maintaining reference relations between repositories
Posted by David Nuescheler <da...@gmail.com>.
hi michael,
> Suppose two repositories, an author and a public repository. You can activate
> content from one to the other. The two repositories are physically separated,
> maybe located on different machines.
the term "activation" has no meaning in the realm of a content
repository. since i know exactly where this term stems from,
i think i understand that you talk about replication or syndication of
content from one repository to the other.
> My use case are references to nodes (e.g. links to a page or an asset) that are
> of subtype mix:referenceable. The challenge we encounter is that the read only
> property 'jcr:uuid' is generated automatically while activating and thus
> references are lost.
> How can you ensure that references in the author repository are respected in
> the public repository?
export/import can keep the uuid's beyond the boundaries of a repository.
it seems like the obvious solution to me... what did you have in mind?
regards,
david