Hi Fabian On Wed, Feb 4, 2009 at 2:04 PM, Fabián Mandelbaum <[email protected]> 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 Cheers Greg
