DM Rule #3: Workspaces are for corresponding nodes.

[David Nuescheler <da...@gmail.com>]

Explanation:
---

JCR introduces the very abstract concept of Workspaces which leaves a
lot of developers unclear on what to do with them. I would like to
propose to put your use of workspaces to the following to test.

If you have a considerable overlap of corresponding nodes (essentially
the nodes with the same UUID) in multiple workspaces you probably put
workspaces to good use.

If there is no overlap of nodes with the same UUID you are probably
abusing workspaces.

Workspaces should not be used for grouping or access control reasons,
even though it may be tempting to put things into a "bucket", I would
recommend to use a "folder" (node) for your bucket.

Workspaces are the boundary for references and query.

Examples:
---
Use workspaces for things like:
- v1.2 of your project vs. a v1.3 of your project
- a "development", "qa" and a "published" state of content
- completely separated applications that should probably run on
separate repositories to begin with ;)

Do not use workspaces for things like:
- user home directories
- distinct content for different target audiences like public,
private, local, ...
- mail-inboxes for different users

Re: DM Rule #3: Workspaces are for corresponding nodes.

[harvey waters <ha...@googlemail.com>]

I'm confused are you saying that I shouldn't use versioning at all as its
not guaranteed to work within a transaction ? I thought that the JSR170
states that versioning is included within a transaction ?

On 7/10/07, Miro Walker <mi...@gmail.com> wrote:
>
> > 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 ?
> Well, in theory, but in practice, versioning does not occur within a
> single transaction. It's possible (and sometimes happens in practice)
> that the workspace is updated but not the version storage, something
> that's pretty awkward to clear up. The problem is that each workspace
> handles its own persistence, with its own database connection or
> whatever. There's no external transaction manager controlling it all,
> so it's possible for the second commit to fail and the first commit is
> not rolled back.
>
> My advice if transactional integrity is critical to your application
> is that you don't use multiple workspaces and you don't use
> versioning. Within a single workspace it should all be pretty safe.
>
> miro
>

Re: DM Rule #3: Workspaces are for corresponding nodes.

[Miro Walker <mi...@gmail.com>]

> 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 ?
Well, in theory, but in practice, versioning does not occur within a
single transaction. It's possible (and sometimes happens in practice)
that the workspace is updated but not the version storage, something
that's pretty awkward to clear up. The problem is that each workspace
handles its own persistence, with its own database connection or
whatever. There's no external transaction manager controlling it all,
so it's possible for the second commit to fail and the first commit is
not rolled back.

My advice if transactional integrity is critical to your application
is that you don't use multiple workspaces and you don't use
versioning. Within a single workspace it should all be pretty safe.

miro

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

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: DM Rule #3: Workspaces are for corresponding nodes.

[harvey waters <ha...@googlemail.com>]

They are very  similar but an audit log includes all the reads as well as
writes (version history). A lot of organisations have to have an audit log
for legal reasons, it would be nice to add it as a system function as a lot
of 'enterprise' type solutions need this kind of functionality.

On 7/10/07, Mark Waschkowski <mw...@gmail.com> wrote:
>
> Hi Harvey,
>
> What is the difference going to be between your audit log and a version
> history, btw?
>
> Mark
>
> On 7/10/07, harvey waters <ha...@googlemail.com> wrote:
> >
> > I was thinking of it in a slightly different way. I could use the audit
> > work
> > space to store the corresponding audit node in (which has the same uuid
> as
> > the node in the data workspace which holds the actual data) as opposed
> to
> > simply stuffing the audit trail in a 'bucket' .  The corresponding node
> > would have a number of child nodes which would be the actual record of
> an
> > access.
> >
> > I guess I'm trying to sperate the two aspects of the node because the
> > audit
> > trail would never be included with the searches in the 'data' workspace
> > and
> > I have a nagging doubt that the audit trail (which could become huge)
> > could
> > effect the performance of the 'data' workspace.
> >
> > In the perfect world though I know I would store the audit trail with
> the
> > actual node so that I could just use node.getAuditTrail()  or have you
> > guys
> > already included that in jsr283 :)
> >
> > On 7/10/07, David Nuescheler <da...@gmail.com> 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
> > >
> >
>
>
>
> --
> Best,
>
> Mark Waschkowski
>

Re: DM Rule #3: Workspaces are for corresponding nodes.

[Mark Waschkowski <mw...@gmail.com>]

Hi Harvey,

What is the difference going to be between your audit log and a version
history, btw?

Mark

On 7/10/07, harvey waters <ha...@googlemail.com> wrote:
>
> I was thinking of it in a slightly different way. I could use the audit
> work
> space to store the corresponding audit node in (which has the same uuid as
> the node in the data workspace which holds the actual data) as opposed to
> simply stuffing the audit trail in a 'bucket' .  The corresponding node
> would have a number of child nodes which would be the actual record of an
> access.
>
> I guess I'm trying to sperate the two aspects of the node because the
> audit
> trail would never be included with the searches in the 'data' workspace
> and
> I have a nagging doubt that the audit trail (which could become huge)
> could
> effect the performance of the 'data' workspace.
>
> In the perfect world though I know I would store the audit trail with the
> actual node so that I could just use node.getAuditTrail()  or have you
> guys
> already included that in jsr283 :)
>
> On 7/10/07, David Nuescheler <da...@gmail.com> 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
> >
>



-- 
Best,

Mark Waschkowski

Re: DM Rule #3: Workspaces are for corresponding nodes.

[harvey waters <ha...@googlemail.com>]

I was thinking of it in a slightly different way. I could use the audit work
space to store the corresponding audit node in (which has the same uuid as
the node in the data workspace which holds the actual data) as opposed to
simply stuffing the audit trail in a 'bucket' .  The corresponding node
would have a number of child nodes which would be the actual record of an
access.

I guess I'm trying to sperate the two aspects of the node because the audit
trail would never be included with the searches in the 'data' workspace and
I have a nagging doubt that the audit trail (which could become huge) could
effect the performance of the 'data' workspace.

In the perfect world though I know I would store the audit trail with the
actual node so that I could just use node.getAuditTrail()  or have you guys
already included that in jsr283 :)

On 7/10/07, David Nuescheler <da...@gmail.com> 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
>

Re: DM Rule #3: Workspaces are for corresponding nodes.

[David Nuescheler <da...@gmail.com>]

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

Re: DM Rule #3: Workspaces are for corresponding nodes.

[harvey waters <ha...@googlemail.com>]

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'.

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 ?

On 7/7/07, David Nuescheler <da...@gmail.com> wrote:
>
> Explanation:
> ---
>
> JCR introduces the very abstract concept of Workspaces which leaves a
> lot of developers unclear on what to do with them. I would like to
> propose to put your use of workspaces to the following to test.
>
> If you have a considerable overlap of corresponding nodes (essentially
> the nodes with the same UUID) in multiple workspaces you probably put
> workspaces to good use.
>
> If there is no overlap of nodes with the same UUID you are probably
> abusing workspaces.
>
> Workspaces should not be used for grouping or access control reasons,
> even though it may be tempting to put things into a "bucket", I would
> recommend to use a "folder" (node) for your bucket.
>
> Workspaces are the boundary for references and query.
>
> Examples:
> ---
> Use workspaces for things like:
> - v1.2 of your project vs. a v1.3 of your project
> - a "development", "qa" and a "published" state of content
> - completely separated applications that should probably run on
> separate repositories to begin with ;)
>
> Do not use workspaces for things like:
> - user home directories
> - distinct content for different target audiences like public,
> private, local, ...
> - mail-inboxes for different users
>

Re: data modelling question

[David Nuescheler <da...@day.com>]

Hi Erol,

I would go for (b), seems the most intuitive.

regards,
david

On 7/27/07, Ünala Erol <Er...@zuerich.ch> wrote:
> dear list,
> i'm a newbie in jcr and currently try to do a datamodel for a small mindmapping webapp. it's a simple app where a user can have several mindmaps. I ended up with 2 possibilities:
>
> a) separate path for users and map-content:
> /mindmapapp/config/users/[user-email]
> ([user-email]: String properties for current email-adress, alias, password)
>
> /mindmapapp/maps/[user-email]/[mindmapname]/{mindmapnodes}
> ([user-email]: with no properties; [mindmapname]: String properties for current mindmapname, description, modified date, Multivalue String property for collaborators)
>
> b) one path:
> /mindmapapp/maps/[user-email]/[mindmapname]/{mindmapnodes}
> ([user-email]:String properties for current email-adress, alias, password ; [mindmapname]: String properties for current mindmapname, description, modified date, Multivalue String property for collaborators)
>
> x) the mindmap-nodes:
> there will be only 3 levels for the first release, does it make sense to structure them something like eg.
> ..[mindmapname]/root/b1/c1 (numbered)
> ..[mindmapname]/root/b1/c10
> ..[mindmapname]/root/b6/c1
>
>
> It woud be great if you could give me some feedback on which way to proceed, thanks!
>
> Erol
>

data modelling question

[Ünala Erol <Er...@zuerich.ch>]

dear list,
i'm a newbie in jcr and currently try to do a datamodel for a small mindmapping webapp. it's a simple app where a user can have several mindmaps. I ended up with 2 possibilities:

a) separate path for users and map-content:
/mindmapapp/config/users/[user-email] 
([user-email]: String properties for current email-adress, alias, password)

/mindmapapp/maps/[user-email]/[mindmapname]/{mindmapnodes}  
([user-email]: with no properties; [mindmapname]: String properties for current mindmapname, description, modified date, Multivalue String property for collaborators)

b) one path:
/mindmapapp/maps/[user-email]/[mindmapname]/{mindmapnodes}  
([user-email]:String properties for current email-adress, alias, password ; [mindmapname]: String properties for current mindmapname, description, modified date, Multivalue String property for collaborators)

x) the mindmap-nodes:
there will be only 3 levels for the first release, does it make sense to structure them something like eg.
..[mindmapname]/root/b1/c1 (numbered)
..[mindmapname]/root/b1/c10
..[mindmapname]/root/b6/c1


It woud be great if you could give me some feedback on which way to proceed, thanks!

Erol

Re: DM Rule #3: Workspaces are for corresponding nodes.

[David Nuescheler <da...@day.com>]

Hi Darren,

thanks for your question.

> I have a question (based on ignorance) of Workspaces.  When you say they are
> a boundary for references and query, is the intent that you can not
> cross-query multiple workspaces?
Yes, this is the case.

> My original thought for one scenario is for Records Management, and having a
> workspace on a per-year basis (making it easy for repository backup).  But,
> still need to support query across all years/workspace.
> Is this a valid scenario for utilizing workspaces?
I think your operational reasoning (re: back-up or performance) may
still be valid,
but from a content modeling standpoint the per year workspace does not seem
to a valid usecase.

I think for better understanding I could maybe simplify the rule to
something like:

"If you use Node.clone() Node.merge() and Node.update() then you
have a usecase for workspaces... otherwise you don't"

Does that make sense?

I think operational or performance considerations can certainly
influence your content model but I think it is important to understand
that a lot of those operational and performance characteristics are
implementation specific and may apply to Jackrabbit but not to
other JCR implementation.

regards,
david

Re: DM Rule #3: Workspaces are for corresponding nodes.

[dhartford <dh...@ghsinc.com>]

I have a question (based on ignorance) of Workspaces.  When you say they are
a boundary for references and query, is the intent that you can not
cross-query multiple workspaces?

My original thought for one scenario is for Records Management, and having a
workspace on a per-year basis (making it easy for repository backup).  But,
still need to support query across all years/workspace.

Is this a valid scenario for utilizing workspaces?


David Nuescheler wrote:
> 
> Workspaces are the boundary for references and query.
> 
> Examples:
> ---
> Use workspaces for things like:
> - v1.2 of your project vs. a v1.3 of your project
> - a "development", "qa" and a "published" state of content
> - completely separated applications that should probably run on
> separate repositories to begin with ;)
> 
> Do not use workspaces for things like:
> - user home directories
> - distinct content for different target audiences like public,
> private, local, ...
> - mail-inboxes for different users
> 
> 

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