You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by qcfireball <qc...@yahoo.com> on 2007/07/05 16:02:09 UTC
Question
I spent about 2 hours looking for the appropriate forum to post this
question. This one is the best I came up with.
Please forgive me, but my question is not Jackrabbit specific.
What I want to do is be able to refer from one node via a property to
another node in a different workspace. For example:
WorkspaceA
root node
Node 001
Property:REFERENCEABLE, value=??? can I refer to Node 00X, UUID
00000123??
WorkspaceB
root node
Node 00X
UUID = 00000123
Is this possible in Jackrabbit? Is this possible in other implementations
of the JSR-170? Is this something that is not defined by the JSR-170? I
have read thru the Spec, and it does not seem to address this, so I am
assuming that the JSR-170 does not address this. It talks about
corresponding nodes (which I am not sure I understand yet), but this does
not seem to address the question I am interested in.
Thanks.
> mjkelleher
> qcfireball@yahoo.com
--
View this message in context: http://www.nabble.com/Question-tf4029888.html#a11446925
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Re: Question
Posted by David Nuescheler <da...@gmail.com>.
Hi,
Thanks for the additional Information.
> Here is what we are trying to accomplish.
> We have several "sites" {Public, Local, National, Press, etc...} and wanted
> to use separate workspaces for each one in order to segment the content.
> However, occasionally, content from one "site" must refer to content from
> another "site". If we implemented this using workspaces, a node from one
> workspace will need to refer to a node from a different workspace.
Sounds like a "grouping" to me... ;)
I think the misconception (and misuse) of workspaces is one
of the most common issues around "Content Modeling" in general.
In the JCR Expert Group we found that we still have to explain
the very abstract concept of Workspaces much more in details and give
some best practices, guidelines and clear indications
on when to use workspaces.
I will try to give it a first shot here:
Workspaces are useful in combination with versioning or
cross-workspace operations (such as merge or update) that
means if you have nodes with the same UUID in various
workspaces it is likely that your usecase is valid.
In case you have no nodes with the same UUID in different
workspaces it is likely that you would be better served by "folders" (nodes
in the hierarchy), since the workspace also is the boundary for
references or query. There are a few usecases that desire this additional
isolation, but one has to be clear of the implications.
So to come back to your datamodel, I would recommend to do something
like: /content/public, /content/national, /content/local, ... This would for
example also allow you to search everything, which may or may not
be a desired sideffect.
Currently I can't see a drawback of modeling things into one workspace.
On a completely different note I would like to mention that (since WebCM is
our core business) I would also discourage the use of of (hard)-references
for almost every usecase in WCM. In WCM I think that dealing with a dangling
reference (in JCRv1.0 pretty much a string, containing a UUID) on an
application
layer is more desirable.
The additional overhead and constraint of the referential integrity on
a content layer
is constricting...
I would certainly be interested in continuing this discussion since I think
that good content modeling guidelines or recommendations are something
that we lack in JCR and the "content" space in general.
regards,
david
Re: Question
Posted by qcfireball <qc...@yahoo.com>.
In reply to your p.s., yes, I meant REFERENCE, not REFERENCEABLE.
Here is what we are trying to accomplish.
We have several "sites" {Public, Local, National, Press, etc...} and wanted
to use separate workspaces for each one in order to segment the content.
However, occasionally, content from one "site" must refer to content from
another "site". If we implemented this using workspaces, a node from one
workspace will need to refer to a node from a different workspace.
David Nuescheler wrote:
>
> Hi,
>
> the JSR-170 spec explicitly states that references are within the
> same workspace only. generally, there are a number of issues with
> cross workspace references. to mention one, your session is
> tied to one workspace and the access to another workspace
> is not obvious without creating another session.
> also, since there can be multiple workspaces with the node
> with that given UUID it would not be trivial to identify the node
> just through the UUID. referential integrity is a whole
> different issue.
>
> In JSR-283 cross repository and cross workspace references
> are considered as a topic to resolve.
>
> In my experience I found that a lot of people that were interested in
> cross workspace references were not really looking for all the
> attributes of a JCR reference and either ended up putting all the data
> into one workspace (rightfully so, since the workspace metaphore is
> frequently
> abused as some grouping or even access control mechanism) or
> used for example UUID's as strings and resolved the reference in the
> application
> with a getByUUID() call on the target workspace.
>
> Maybe you can outline your usecase a little bit more in detail, I
> would be happy to see what suggestions I could come up with.
>
> regards,
> david
>
>
> .ps: I read the property in your example as a "reference" property,
> since there is no
> "referenceable" property. I assume that's correct, right?
>
> On 7/5/07, qcfireball <qc...@yahoo.com> wrote:
>>
>> I spent about 2 hours looking for the appropriate forum to post this
>> question. This one is the best I came up with.
>>
>> Please forgive me, but my question is not Jackrabbit specific.
>>
>> What I want to do is be able to refer from one node via a property to
>> another node in a different workspace. For example:
>> WorkspaceA
>> root node
>> Node 001
>> Property:REFERENCEABLE, value=??? can I refer to Node 00X,
>> UUID
>> 00000123??
>>
>> WorkspaceB
>> root node
>> Node 00X
>> UUID = 00000123
>>
>> Is this possible in Jackrabbit? Is this possible in other
>> implementations
>> of the JSR-170? Is this something that is not defined by the JSR-170? I
>> have read thru the Spec, and it does not seem to address this, so I am
>> assuming that the JSR-170 does not address this. It talks about
>> corresponding nodes (which I am not sure I understand yet), but this does
>> not seem to address the question I am interested in.
>>
>> Thanks.
>>
>> > mjkelleher
>> > qcfireball@yahoo.com
>> --
>> View this message in context:
>> http://www.nabble.com/Question-tf4029888.html#a11446925
>> Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Question-tf4029888.html#a11449712
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Re: Question
Posted by Christoph Kiehl <ch...@sulu3000.de>.
David Nuescheler wrote:
> In my experience I found that a lot of people that were interested in
> cross workspace references were not really looking for all the
> attributes of a JCR reference and either ended up putting all the data
> into one workspace (rightfully so, since the workspace metaphore is
> frequently
> abused as some grouping or even access control mechanism) or
> used for example UUID's as strings and resolved the reference in the
> application
> with a getByUUID() call on the target workspace.
Could you outline some valid use cases for using multiple workspaces? The only
one I found was having two workspaces: one for published content and one for
content. But this is just for our use case which is centered around CMS,
editing, publishing. I'm sure there are much more situations were it is worth to
consider using multiple workspaces. This might be helpful for newcomers as well
to show what jackrabbit could be used for.
Cheers,
Christoph
Re: Question
Posted by David Nuescheler <da...@gmail.com>.
Hi,
the JSR-170 spec explicitly states that references are within the
same workspace only. generally, there are a number of issues with
cross workspace references. to mention one, your session is
tied to one workspace and the access to another workspace
is not obvious without creating another session.
also, since there can be multiple workspaces with the node
with that given UUID it would not be trivial to identify the node
just through the UUID. referential integrity is a whole
different issue.
In JSR-283 cross repository and cross workspace references
are considered as a topic to resolve.
In my experience I found that a lot of people that were interested in
cross workspace references were not really looking for all the
attributes of a JCR reference and either ended up putting all the data
into one workspace (rightfully so, since the workspace metaphore is frequently
abused as some grouping or even access control mechanism) or
used for example UUID's as strings and resolved the reference in the application
with a getByUUID() call on the target workspace.
Maybe you can outline your usecase a little bit more in detail, I
would be happy to see what suggestions I could come up with.
regards,
david
.ps: I read the property in your example as a "reference" property,
since there is no
"referenceable" property. I assume that's correct, right?
On 7/5/07, qcfireball <qc...@yahoo.com> wrote:
>
> I spent about 2 hours looking for the appropriate forum to post this
> question. This one is the best I came up with.
>
> Please forgive me, but my question is not Jackrabbit specific.
>
> What I want to do is be able to refer from one node via a property to
> another node in a different workspace. For example:
> WorkspaceA
> root node
> Node 001
> Property:REFERENCEABLE, value=??? can I refer to Node 00X, UUID
> 00000123??
>
> WorkspaceB
> root node
> Node 00X
> UUID = 00000123
>
> Is this possible in Jackrabbit? Is this possible in other implementations
> of the JSR-170? Is this something that is not defined by the JSR-170? I
> have read thru the Spec, and it does not seem to address this, so I am
> assuming that the JSR-170 does not address this. It talks about
> corresponding nodes (which I am not sure I understand yet), but this does
> not seem to address the question I am interested in.
>
> Thanks.
>
> > mjkelleher
> > qcfireball@yahoo.com
> --
> View this message in context: http://www.nabble.com/Question-tf4029888.html#a11446925
> Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
>
>