Explanation and use cases of JCR workspace for human beings

3
votes

Could please anybody interpret JCR 2.0 specification in regard to JCR workspaces ?

I understand that a session is always bound to exactly one persistent workspace, though a single persistent workspace may be bound to multiple sessions.

Which probably relates to versioning and transactions, though I don't know why.

Some observations :

  • references are only possible between nodes of the same workspace
  • executing a query will always be targeted to a single workspace

Workspaces seem to be about nodes that represent the same content (same UUID), in :

  • different versions of "something", project maybe ?
  • different phase of workflow

And shouldn't be used for ACL.

Also in JackRabbit, each workspace has its persistence manager. Whereas ModeShape has a connector for source - workspace independent.

1
workspacejackrabbitjcrmodeshape
A ModeShape connector is responsible for reading/writing content for a repository and its workspaces. This can get more complicated when federating, as the federation connector for the repository uses multiple other connectors. Plus, it makes it easier to dynamically create workspaces. So, yes, this is different than how Jackrabbit works. But behavior/use of workspaces within Jackrabbit and ModeShape are the same, since it's dictated by the JSR-283 specification. IMO, it's more important to understand how workspaces work/behave in the spec than using configuration to figure that out. – Randall Hauch

1 Answers

6
votes

David's model ( http://wiki.apache.org/jackrabbit/DavidsModel ) Rule #3 recommends using workspaces only if you need clone(), merge() or update(). For the vast majority of JCR applications, this means not using workspaces. Putting things under different paths, setting specific property values or mixin node types on them and using JCR's versioning covers the versioning and workflow use cases that you mention.

To manage print jobs for example, you could simply move them between JCR folders named "new", "in-progress", "rejected" and "done". That's how it is done in some unix versions, using filesystem folders. JCR allows you to do the same, while benefitting from its "filesystem on steroids" features, so as to keep things very simple, transparent and efficient.

Note also David's Rule #5: references are harmful - we (Apache Sling and Day/Adobe CQ /CRX developers) tend to just use paths instead, as looser and more flexible references.

And as you mention queries: we also use very few of those - navigation in a JCR tree is much more efficient if your content model's path structure makes sense for the most common use cases.