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