On 5/23/07, Shaun Barriball <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] Sent: 23 May 2007 10:00 To: [email protected] Subject: Re: getNodeByUUID vs Reference Properties hi shaun, On 5/23/07, Shaun Barriball <[EMAIL PROTECTED]> 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. > > > > > > > >
