jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fabián Mandelbaum <fmandelb...@gmail.com>
Subject Re: One Repository or Many?
Date Fri, 31 Jul 2009 12:33:06 GMT
On Fri, Jul 31, 2009 at 6:44 AM, Alexander Klimetschek<aklimets@day.com> wrote:
> 2009/7/31 Fabián Mandelbaum <fmandelbaum@gmail.com>:
>> One more question though, reading (the last part of) your answer I
>> understand that workspaces can be used to separate storage for
>> different customers. Did I understand correctly? Because according to
>> David's model (http://wiki.apache.org/jackrabbit/DavidsModel) this
>> practice would be discouraged.
> That's why I said it depends.... Workspaces from a feature point of
> view are oriented for creating separate branches of your content and
> allow for continuous merging/copying/cloning of nodes (and subtrees)
> from one branch to the other. Also all workspaces share a common
> version history storage, because if nodes were cloned from one ws to
> the other, they share the same UUID and also the same version history.
> But this doesn't restrict you from having one workspace for each
> customer if you never clone any nodes and if a common version storage
> (that cannot be purged easily if one customer's workspace is removed)
> is not a problem.
> What I would discourage is having one workspace per user, which is an
> idea that is brought up from time to time on the mailing list. Because
> users share a common application/environment it does not make sense to
> separate them.
> Regards,
> Alex
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com

Hello Alex, thanks again for your answer.

The shared version history rules out the
one-jcr-workspace-per-customer idea then, because our CMS intends to
provide revision management using JCR's versionning, right? Or I can
do the one-jcr-workspace-per-customer knowing that the version storage
cannot be purged and may become 'dirty' should I decide to 'delete' a

Fabián Mandelbaum
IS Engineer

View raw message