jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Klebus <g...@klebus.com>
Subject Re: Workspaces and separating content storage
Date Fri, 06 Feb 2009 22:19:09 GMT
Hi Fabian

On Wed, Feb 4, 2009 at 2:04 PM, Fabián Mandelbaum <fmandelbaum@gmail.com> wrote:
> Hello there,
>    I've read David's Model wiki
> (http://wiki.apache.org/jackrabbit/DavidsModel) and many other JR
> articles on the Internet (don't have their URLs handy). One of the
> articles I've read spoke about JR as a kind of "better DB than a DB, for
> content-related stuff".
>    I have a project where we need to store content for different
> accounts/clients/whatever_you_want_to_call_them and chosen JackRabbit as
> the "storage engine". You may be able to see the architecture here:
> http://trac.calenco.com/wiki/UserScenarioTechSpecs#Contentstore

I noticed on this page you already seem to have suggested another
approach than the one with repo-per-account [1].

>    Right now, I have one JR repo for each account, so each account is
> self-contained, but it's proving a bit messy to handle and the content
> model is changing all the time (not because what I need to store
> changes, but because of the way I store it). I've downloaded and played
> a bit with Jackrabbit Standalone Server 1.5.2 jar and like what it
> offers (one instance running only, 'out of the box' webdav, simpler
> deployment, etc.).
>    Now, with a DB one doesn't have a DB server instance running per
> each account one needs to handle, but only *1* DB server instance and as
> many tables and rows as the developer modelled.
>    With all this in mind, which would be your recommendations for
> storing content for different accounts where each account should not be
> able to see content from the other? Is a workspace-per-account a viable
> solution or will it "break my machine" if I even dare to try?

I wouldn't go for repository per account here.

My thinking would be storing everything in one repository, with a
separate node hierarchy per account/client/what-have-you, and access
rights set up correctly so that users (clients) can only see what they
are supposed to see. Plus starting unstructured at the beginning.

I guess you've figured the same based on David's model here [1],
right? Let us know how if/how this new structure works for you.

You normally only need multiple workspaces for one application if you
need to leverage the inter-workspace JCR operations, or have
specialized use for them. Using the DB-example, a workspace would give
you everything you'd have in a database instance (or schema) - only
that instead of a fixed relational model with tables/rows and
relationships modeled with IDs, you've got freedom of hierarchy,
unstructured-to-fully-structured flexibility and other JCR goodies.

[1] http://trac.calenco.com/wiki/UserScenarioTechSpecs#Alternative2009-02-04ContentStorageModel


View raw message