jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shaun Barriball" <sbarr...@yahoo.co.uk>
Subject RE: getNodeByUUID vs Reference Properties
Date Wed, 23 May 2007 10:19:18 GMT
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?

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