Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of lists@nabble.com designates
 216.139.236.158 as permitted sender)
Message-ID: <21369165.post@talk.nabble.com>
Date: Fri, 9 Jan 2009 01:46:34 -0800 (PST)
From: quipere <jquipere@hotmail.com>
To: users@jackrabbit.apache.org
Subject: Re: Issue with versioning of cloned nodes
In-Reply-To: <510143ac0901090109j7f8fdc28re724c013cc9dfea8@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <eb7e2190707070413r1374e2e9o1fdbe86338f05d4c@mail.gmail.com>
 <235bf4ca0707100131p207e8993jc58e1954005e53e7@mail.gmail.com>
 <eb7e2190707100254o649d6cf6m2d3df757906ba6bf@mail.gmail.com>
 <17142446.post@talk.nabble.com>
 <510143ac0805090029p18ec3c12sa6c13600f76a5f98@mail.gmail.com>
 <21356635.post@talk.nabble.com>
 <c3ac3bad0901081528m533f3b47oc47fddaba4a7631c@mail.gmail.com>
 <21368374.post@talk.nabble.com>
 <510143ac0901090109j7f8fdc28re724c013cc9dfea8@mail.gmail.com>


Yes we have thought about this. Only the problem is, we need to be able to
query the contents of the nodes. It's not binary but our nodes are xml
files. The files are not really that large, but we use a lot of them, over
multiple workspaces. So this creates a lot of redundancy. These nodes need
to be as corresponding nodes in every workspace since we use references to
these xml files/nodes in different workspaces. Cross workspace references
should do the trick, but I know that's not possible because of the
versioning mechanisme.


Jukka Zitting wrote:
> 
> Hi,
> 
> On Fri, Jan 9, 2009 at 9:51 AM, quipere <jquipere@hotmail.com> wrote:
>> I know the versionhistory is shared over workspaces. But I like to know
>> whether the versionable node is copied in every workspace where it is
>> used,
>> or just a ref to the node in the shared versionhistory since the data of
>> the
>> node is already stored in the versionhistory. I could imagine that the
>> node
>> will only be fysically copied in the workspace when it is checked out.
> 
> There is a separate copy of the node in each workspace where it exists.
> 
> The solution against excessive disk usage (and for major performance
> improvements) when handling separate copies of large nodes (ones with
> large binary properties) is the data store feature that ensures that
> only a single copy of any one binary value is kept in the repository.
> Then your nodes would still be separate copies, but all their binary
> properties would be shared.
> 
> BR,
> 
> Jukka Zitting
> 
> 

-- 
View this message in context: http://www.nabble.com/DM-Rule--3%3A-Workspaces-are-for-corresponding-nodes.-tp11477567p21369165.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.