Issue with versioning of cloned nodes

[saurav gangulyy <vi...@yahoo.com>]

Hi,
I clone a versionable node1 into workspace2 from workspace1, with base
version 1.0. And I checkout and checkin node1 in workspace1, and I checkout
and checkin node1 in workspace2. Base Version in both workspaces should be
same(1.1) but version in workspace1 is 1.1, and in workspace2 is 1.1.1. What
is the reason for this unexpected behaviour? And what is the way to maintain
version consistency in two workspaces?(We have to checkout and checkin both
workspaces seperately, we can't use node.update()) .

Thanks and regards,
Vijay Makhija


David Nuescheler wrote:
> 
> Hi Harvey,
> 
>> So an 'audit log' would be a good reason to setup a new workspace. We're
>> thinking here that the audit log is a different perspective (or perhaps
>> aspect) of the node in the main 'data workspace'.
> I don't think that generally speaking an audit log for a "main data"
> workspace
> would benefit from an individual workspace. Segmenting by "content type"
> generally is not a good usecase for workspaces.
> 
> "Corresponding nodes" (as specified in the JCR spec) are essentially
> nodes with the same UUID in different workspaces, not nodes that
> are related to each other.
> I would not expect any "corresponding nodes" in an audit log, but may
> I am overlooking something here.
> 
> Personally, I would recommend to have a "/myapp/auditlog" node in the
> "main data"
> workspace to record all the information there.
> 
>> Is it possible to get a session to write to two workspaces within a
>> transaction, surely this must be possible as versioning occurs within a
>> transaction ?
> Versioning is a little bit different since it is handled inside the
> repository.
> 
> It would be possible to have two sessions, and enroll both into the
> same XA transaction. However, for the audit log application I would really
> recommend to keep it simple and store the information in the same
> workspace unless there is a good reason not to do that.
> 
> regards,
> david
> 
> 

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

Re: Issue with versioning of cloned nodes

[quipere <jq...@hotmail.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 <jq...@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.

Re: Issue with versioning of cloned nodes

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Fri, Jan 9, 2009 at 9:51 AM, quipere <jq...@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

Re: Issue with versioning of cloned nodes

[quipere <jq...@hotmail.com>]

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.

thx


Alexander Klimetschek wrote:
> 
> On Thu, Jan 8, 2009 at 6:33 PM, quipere <jq...@hotmail.com> wrote:
>> I use a very large versionable Node "a". Which has 3 versions in
>> versionhistory (1.0, 1.1 and 1.2). When I create lets say 3 workspaces
>> which
>> all use node "a" as version 1.0, does this triple the use of disk
>> resources
>> or do these multiple workspaces just keep references to the
>> versionhistory?
>> So node "a" version 1.0 is just stored once in versionhistory and that's
>> it.
> 
> If you copy node a into all workspaces by using clone(), they will
> share the same version history. Technically there is only one version
> storage ("workspace") for the entire repository that is shared by all
> workspaces because of that JCR feature.
> 
> Regards,
> Alex
> 
> -- 
> Alexander Klimetschek
> alexander.klimetschek@day.com
> 
> 

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

Re: Issue with versioning of cloned nodes

[Alexander Klimetschek <ak...@day.com>]

On Thu, Jan 8, 2009 at 6:33 PM, quipere <jq...@hotmail.com> wrote:
> I use a very large versionable Node "a". Which has 3 versions in
> versionhistory (1.0, 1.1 and 1.2). When I create lets say 3 workspaces which
> all use node "a" as version 1.0, does this triple the use of disk resources
> or do these multiple workspaces just keep references to the versionhistory?
> So node "a" version 1.0 is just stored once in versionhistory and that's it.

If you copy node a into all workspaces by using clone(), they will
share the same version history. Technically there is only one version
storage ("workspace") for the entire repository that is shared by all
workspaces because of that JCR feature.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: Issue with versioning of cloned nodes

[quipere <jq...@hotmail.com>]

Hi,

I use a very large versionable Node "a". Which has 3 versions in
versionhistory (1.0, 1.1 and 1.2). When I create lets say 3 workspaces which
all use node "a" as version 1.0, does this triple the use of disk resources
or do these multiple workspaces just keep references to the versionhistory?
So node "a" version 1.0 is just stored once in versionhistory and that's it.

grt
quipere



Jukka Zitting wrote:
> 
> Hi,
> 
> On Fri, May 9, 2008 at 10:04 AM, saurav gangulyy
> <vi...@yahoo.com> wrote:
>> I clone a versionable node1 into workspace2 from workspace1, with base
>> version 1.0. And I checkout and checkin node1 in workspace1, and I
>> checkout
>> and checkin node1 in workspace2.
> 
> Checkout just makes a node "writable", i.e. it doesn't modify the base
> version of the node. So both of your checkins will create a new
> version with 1.0 as a predecessor.
> 
>> Base Version in both workspaces should be same(1.1) but version in
>> workspace1
>> is 1.1, and in workspace2 is 1.1.1. What is the reason for this
>> unexpected behaviour?
> 
> As explained above, your checkins create two branches in the version
> history.
> 
> If you want both checkins to be a part of the same branch in the
> version history, you need to update (or merge, or restore) the node in
> workspace2 to version 1.1 before checking it in. But in this case the
> base version of the node in workspace1 would still be 1.1, and in
> workspace2 the base version would be 1.2.
> 
>> And what is the way to maintain  version consistency in two workspaces?
> 
> I'm not sure what you mean by "version consistency" here. What's your use
> case?
> 
>> (We have to checkout and checkin both workspaces seperately, we can't
>> use node.update()) .
> 
> Checkout and checkin will only move the base version of a node to the
> new checked in version created by checkin. You need to use update,
> merge, or restore to "rebase" a node to a different base version.
> 
> BR,
> 
> Jukka Zitting
> 
> 

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

Re: Issue with versioning of cloned nodes

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Fri, May 9, 2008 at 10:04 AM, saurav gangulyy
<vi...@yahoo.com> wrote:
> I clone a versionable node1 into workspace2 from workspace1, with base
> version 1.0. And I checkout and checkin node1 in workspace1, and I checkout
> and checkin node1 in workspace2.

Checkout just makes a node "writable", i.e. it doesn't modify the base
version of the node. So both of your checkins will create a new
version with 1.0 as a predecessor.

> Base Version in both workspaces should be same(1.1) but version in workspace1
> is 1.1, and in workspace2 is 1.1.1. What is the reason for this unexpected behaviour?

As explained above, your checkins create two branches in the version history.

If you want both checkins to be a part of the same branch in the
version history, you need to update (or merge, or restore) the node in
workspace2 to version 1.1 before checking it in. But in this case the
base version of the node in workspace1 would still be 1.1, and in
workspace2 the base version would be 1.2.

> And what is the way to maintain  version consistency in two workspaces?

I'm not sure what you mean by "version consistency" here. What's your use case?

> (We have to checkout and checkin both workspaces seperately, we can't
> use node.update()) .

Checkout and checkin will only move the base version of a node to the
new checked in version created by checkin. You need to use update,
merge, or restore to "rebase" a node to a different base version.

BR,

Jukka Zitting