jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Umashanthi Pavalanathan <umashant...@gmail.com>
Subject Re: Linking JCR Nodes
Date Wed, 16 Feb 2011 19:54:36 GMT
On Wed, Feb 16, 2011 at 2:30 PM, Alexander Klimetschek
<aklimets@adobe.com>wrote:

> On 16.02.11 06:03, "Umashanthi Pavalanathan" <umashanthip@gmail.com>
> wrote:
> >As I understood, keeping a list of node references of other nodes is one
> >option. But I am not sure how much feasible it will since that list might
> >grow and shrink vastly.
>
> Yes, in most cases, soft references using path strings is much better than
> hard references. See also http://wiki.apache.org/jackrabbit/DavidsModel
> (rule #7).
>
> >Can you please explain about the concept of Reference and WeakReferences
> >[1][2] ?
>
> These are basically the options for referencing in JCR 2.0, from hardest
> to softest variant:
>
> (1) REFERENCE: Hard reference, using UUID internally, enforced, with
> Node.getReferences() automatically giving you all nodes pointing to this
> node:
> http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#3.6.1.12%20REFEREN
> CE
>
> (2) WEAKREFERENCE: Weak reference, using UUID internally, not enforced,
> with Node.getWeakReferences() automatically giving you all nodes pointing
> to this node:
> http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#3.6.1.11%20WEAKREF
> ERENCE
>
> (3) PATH: Soft reference, using a path string, only the path syntax is
> validated, but existence of the target is not enforced:
> http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#3.6.1.10%20PATH
>
> (4) STRING: Soft reference, using a path string, plain string property,
> nothing is enforced:
> http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#3.6.1.1%20STRING
>
> In most cases I would go for (3) or (4).
>

Thanks Alex for your detailed explanation. I believe I got the idea. Will
ask questions here if I get any during implementation.


Thanks,
~Umashanthi


>
> Regards,
> Alex
>
> --
> Alexander Klimetschek
> Developer // Adobe (Day) // Berlin - Basel
>
>
>
>
>

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