references best-practises?

[Kristian Rink <ka...@zimmer428.net>]

Folks;

being into trying to remodel parts of our system structure using JCR /
Jackrabbit, I wonder what is the most "sane" ways of dealing with references
 in a JCR repository in general and, more specifically, in Jackrabbit?

Our use case is like this:

- We do have a "central" document management structure where everything
stored in our system is kept in a global hierarchy. Most of the things kept
in there are large binary files with an extensive bunch of properties
attached to them.

- Initially, users all should see this "global hierarchy", but they also
should be capable of "collecting" nodes off the global hierarchy in a
custom, self-defined sub-hierarchy where they can keep information sorted
the way they need it. This should, however, happen to be effective (thus
copying a node containing vast amount of binary content a dozen of times at
worst doesn't seem a sane way) and consistent (so, again, copying nodes
seems a no-go as it would make updating things more difficult given one
decides to eventually edit the content of the node).

- Asides a custom application, users should be capable of accessing the
repository (or at least parts of) using "generic" tools (WebDAV, most
specifically). Plus, they also should in the future be capable of exporting
their hierarchy of the repository as XML, containing all data they did
collect there for use with a "standalone" client (i.e. an application
including an embedded JCR repository to browse an archived tree of data).


>From a Unix system point of view, the idea of symlinks comes to mind.
Browsing the web a little, I found several resources on references in JCR /
Jackrabbit, leaving me with two options to consider:

(a) Use "references"; following [1] which outlines that at least this is
possible somehow. Asides not yet having figured out how to get this done
correctly, some of the drawbacks outline in [1] sound sane enough to think
twice.

(b) Use some "reference property" in order to, in a node, keep some UUID or
path or whatever telling where to find the actual content.


Overally, I am unsure what to do. Basically (b) seems most straightforward,
but what I have seen/read so far, doing a simple XML export in such a case
wouldn't eventually dereference my references, plus I am not sure what would
happen, in such a case, accessing the repository using WebDAV.

So... what are your thoughts on that? What's your approach in situations in
which (sym-)links seem required? Any other ideas?

TIA and all the best,
Kristian


[1]http://wiki.apache.org/jackrabbit/DavidsModel#head-ed794ec9f4f716b3e53548be6dd91b23e5dd3f3a


-- 
Kristian Rink
cell    :  +49 176 2447 2771
business: http://www.planconnect.de
personal: http://pictorial.zimmer428.net
"Past midnight. Never knew such silence.
The earth might be uninhabited..."
//beckett / krapp's last tape//

Re: references best-practises?

[Alexander Klimetschek <ak...@day.com>]

On Mon, May 25, 2009 at 1:29 PM, Kristian Rink <ka...@zimmer428.net> wrote:
> Yes, I thought so as well, especially talking about the "descriptive" part
> of the story.  However, that way I lose the idea of "dereferencing" links
> when using XML export (at least without re-implementing XML export itself
> manually, that is), am I right?

Right, but that depends on how the exported XML is used. It would
still contain the references as paths that should (at least in
document view) be correct XPaths in the XML as well.

Otherwise writing your own customized XML exporter is not that hard.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: references best-practises?

[Kristian Rink <ka...@zimmer428.net>]

Hi Alex;

and first off, thanks a bunch for your feedback on this.

Alexander Klimetschek schrieb:
> On Fri, May 22, 2009 at 1:32 AM, Kristian Rink <ka...@zimmer428.net> wrote:
>> (b) Use some "reference property" in order to, in a node, keep some UUID or
>> path or whatever telling where to find the actual content.
> 
> I'd use a (single or multivalue) string property containing the path
> of the reference target. Albeit this requires some extra application
> code (especially when the targets are deleted, can be done with
> observation), it is the most flexible and transparent approach (paths
> are more descriptive than UUIDs and self-made ids need additional
> interpretion by application code).

Yes, I thought so as well, especially talking about the "descriptive" part
of the story.  However, that way I lose the idea of "dereferencing" links
when using XML export (at least without re-implementing XML export itself
manually, that is), am I right?

Cheers,
Kristian


-- 
Kristian Rink
cell    :  +49 176 2447 2771
business: http://www.planconnect.de
personal: http://pictorial.zimmer428.net
"Past midnight. Never knew such silence.
The earth might be uninhabited..."
//beckett / krapp's last tape//

Re: references best-practises?

[Alexander Klimetschek <ak...@day.com>]

On Fri, May 22, 2009 at 1:32 AM, Kristian Rink <ka...@zimmer428.net> wrote:
> (b) Use some "reference property" in order to, in a node, keep some UUID or
> path or whatever telling where to find the actual content.

I'd use a (single or multivalue) string property containing the path
of the reference target. Albeit this requires some extra application
code (especially when the targets are deleted, can be done with
observation), it is the most flexible and transparent approach (paths
are more descriptive than UUIDs and self-made ids need additional
interpretion by application code).

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: references best-practises?

[Julian Reschke <ju...@gmx.de>]

Kristian Rink wrote:
> Hi Julian, *;
> 
> and, first off, thank you very much for your input on that...
> 
> Julian Reschke schrieb:
>> Actually, from a Unix system point of view, I think that *hard* links
>> should come to mind first.
> 
> Well... actually, not from my point of view. :) In our environment, I
> definitely would want users to "see" items are just "links" to other items
> living somewhere in the system - I assume this would drastically reduce the
> amount of questions and complaints regarding "duplicate" pieces of
> information stored in different parts of the structure.
> ...

Ok, in that case it would probably make sense to model symlinks using 
the originally proposed nt:link node type (potentially using a 
WEKREFERENCE instead of a REFERENCE).

BR, Julian

Re: references best-practises?

[Kristian Rink <ka...@zimmer428.net>]

Hi Julian, *;

and, first off, thank you very much for your input on that...

Julian Reschke schrieb:
> Actually, from a Unix system point of view, I think that *hard* links
> should come to mind first.

Well... actually, not from my point of view. :) In our environment, I
definitely would want users to "see" items are just "links" to other items
living somewhere in the system - I assume this would drastically reduce the
amount of questions and complaints regarding "duplicate" pieces of
information stored in different parts of the structure.

> The equivalent of them have been introduced in JCR 2.0 as "shareable
> nodes", so you can experiment with them in Jackrabbit trunk already.

I will have a look at the code nevertheless, thanks very much for the
pointer. :)

Cheers,
Kristian

-- 
Kristian Rink
cell    :  +49 176 2447 2771
business: http://www.planconnect.de
personal: http://pictorial.zimmer428.net
"Past midnight. Never knew such silence.
The earth might be uninhabited..."
//beckett / krapp's last tape//

Re: references best-practises?

[Julian Reschke <ju...@gmx.de>]

Kristian Rink wrote:
> ...
>>>From a Unix system point of view, the idea of symlinks comes to mind.
> Browsing the web a little, I found several resources on references in JCR /
> Jackrabbit, leaving me with two options to consider:
> 
> (a) Use "references"; following [1] which outlines that at least this is
> possible somehow. Asides not yet having figured out how to get this done
> correctly, some of the drawbacks outline in [1] sound sane enough to think
> twice.
> 
> (b) Use some "reference property" in order to, in a node, keep some UUID or
> path or whatever telling where to find the actual content.
> ...

Actually, from a Unix system point of view, I think that *hard* links 
should come to mind first.

The equivalent of them have been introduced in JCR 2.0 as "shareable 
nodes", so you can experiment with them in Jackrabbit trunk already.

BR, Julian