jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg" <stefan.guggisb...@gmail.com>
Subject Re: getNodeByUUID vs Reference Properties
Date Wed, 23 May 2007 12:39:58 GMT
On 5/23/07, Shaun Barriball <sbarriba@yahoo.co.uk> wrote:
> Hi Stefan,
>
> RE "i can't follow you here, sorry. could you please elaborate?"
>
> > We are currently using Solution B rather than Solution A to ensure we
> > do not cause versioning of "Foo" each time "Bar" changes.
>
> To clarify, in Java terms I'm after:
>
> public class Foo implements Serializable {
>    private transient Bar bar;
> ...
>
> The type "Foo" is used to represent content.
>  1) When items of type "Foo" are saved this triggers some ancillary logic,
> via event listeners.
>  2) If/when we make "Foo" versionable I was initially assuming that we'd be
> creating a long version history due to "Bar" changes.
>
> For reasons 1) and 2) I didn't want to generate save() operations on "Foo"
> when the system recaculates the transient "Bar" value. Hence the use of a
> reference property for "Bar".
>
> But after thought and reviewing the Node API I see save() and checkin() are
> distinct operations so my reasoning above may be flawed given you can
> perform separate save() and checkin() operations.
>
> So....in summary......is the best solution to use:
>
> [acme:Foo] > ..usual suspects
>         - acme:bar (acme:Bar) IGNORE
>
> Using "IGNORE" hopefully achieves the "transient" requirement and we'll only
> call save on the acme:Bar node, not acme:Foo, when it is updated?

correct. IGNORE simply causes the state of acme:bar not to be included
in the version of an acme:Foo node. furthermore, acme:Foo only needs
to be saved when an acme:Bar node has been added. once the acme:Bar
node exists you can save it independantly of its parent.

cheers
stefan

>
> Regards,
> Shaun.
>
> -----Original Message-----
> From: Stefan Guggisberg [mailto:stefan.guggisberg@gmail.com]
> Sent: 23 May 2007 10:00
> To: users@jackrabbit.apache.org
> Subject: Re: getNodeByUUID vs Reference Properties
>
> hi shaun,
>
> On 5/23/07, Shaun Barriball <sbarriba@yahoo.co.uk> wrote:
> > Hi all,
> > We have a Node Type "Foo" which may optionally be associated with
> > another Node Type "Bar".
> > "Bar" is logically owned by "Foo" but is effectively transient e.g. it
> > is deleted and recreated frequently.
> >
> > 3 potential solutions:
> >
> > Solution A:
> >  [acme:Foo] > ..usual suspects
> >         - acme:bar (acme:Bar) COPY
> >
> > Solution B:
> >  [acme:Foo] > ..usual suspects
> >         acme:bar (reference) COPY
> >         < 'acme:Bar'
> >
> > Solution C:
> >  [acme:Foo] > ..usual suspects
> >         - acme:barUUID (string) COPY
> >
> > We are currently using Solution B rather than Solution A to ensure we
> > do not cause versioning of "Foo" each time "Bar" changes.
>
> i can't follow you here, sorry. could you please elaborate?
>
> >
> > The issue is that basic delete is not permitted on any "Foo" if it has
> > a "Bar" using Solution B. Ideally we'd want the concept of cascade
> > delete where the "Bar" is deleted if the "Foo" is deleted but without
> > having to use Solution A.
> >
> > If we use Solution C then we weaken the relationship to being UUID
> > based rather than an integral relationship. This is a workaround to
> > address the basic requirements for association and deletion, although
> > we'll need to tidy up unused Bar instances.
> >
> > If Solution C is used then we'll need to use getNodeByUUID() rather
> > than following a reference property. Is there a performance drop in
> > using getNodeByUUID vs getProperty().getNode()?
>
> no. both calls boil down to the same internal operation (which is btw very
> efficient).
>
> cheers
> stefan
>
> >
> > Regards,
> > Shaun.
> >
> >
> >
> >
> >
> >
> >
> >
>
>

Mime
View raw message