DM Rule #3: Workspaces are for corresponding nodes.

[David Nuescheler]

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

[HarveyWaters]

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 <david.nuescheler@...> 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
>

[David Nuescheler]

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

[Miro Walker-2]

> 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

[HarveyWaters]

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

[HarveyWaters]

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 <miro.walker@...> 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
>

[Mark Waschkowski]

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 <harvey.waters@...> 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 <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
> >
>

--
Best,

Mark Waschkowski

[HarveyWaters]

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 <mwaschkowski@...> 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 <harvey.waters@...> 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 <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
> > >
> >
>
>
>
> --
> Best,
>
> Mark Waschkowski
>

[dhartford]

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

[David Nuescheler-3]

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

[Ünala Erol]

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

[David Nuescheler-3]

Hi Erol,

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

regards,
david

On 7/27/07, Ünala Erol <Erol.Uenala@...> 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
>

[saurav gangulyy]

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

[Jukka Zitting]

Hi,

On Fri, May 9, 2008 at 10:04 AM, saurav gangulyy
<vijay_makhija@...> 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