You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Alan Chaney <al...@writingshow.com> on 2009/12/17 01:00:44 UTC
Practical limitations on the number of workspaces
Hi
I'm a complete newbie to using Jackrabbit. I'm designing a system in
which I intend to manage a very large number of multimedia assets using
JR workspaces as libraries. The library would have different node types
depending upon the type of asset, which can be of various types, from a
few lines of text to multi-megabyte binary files.
Sorry if the following appears a dumb question, but I haven't yet really
got very much experience with the practical side of JR. I've read both
JSR 170 and JSR 283 but reading the specs is no substitute for hands on
practical experience. Ideally I'd experiment, but sadly I'm under a bit
of time pressure and so I'm hoping that people on this would be able to
give me some advice.
In our application users have their own "workbench" which is like a
playground in which they can experiment with assets. It seems to me that:
1. I could implement the domain objects for the workbench and use an ORM
to persist the relationships between this domain objects. These would
contain references to nodes in the library which would be JR and this
would provide the information required to deliver the data to the user.
or
2. I could implement the "workbench" domain structure as jackrabbit
nodes and have one workspace for each user. This may be 1000s of users
(eventually). What are the practical limits on the number of jackrabbit
workspaces - is it possible to have 100s or 1000s? The individual users
workspaces would have references to some of the library items but the
library would not have any references to the users items.
Regards
Alan Chaney
Re: Practical limitations on the number of workspaces
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Dec 17, 2009 at 5:56 PM, Rakesh Vidyadharan <ra...@sptci.com> wrote:
> ...In general unless you are dealing with content (automatically
> index documents etc), JCR is unlikely to be the best solution....
Automatic indexing is just one of the benefits of JCR...observation,
unstructured/structured, hierarchies, WebDAV, versioning, multi-value
properties...there's much more to it ;-)
-Bertrand
Re: Practical limitations on the number of workspaces
Posted by Rakesh Vidyadharan <ra...@sptci.com>.
On 17 Dec 2009, at 10:46, Guo Du wrote:
> On Thu, Dec 17, 2009 at 3:15 PM, Alan Chaney <al...@writingshow.com> wrote:
>> (which is a 3D modelling system) requires a very large number of
>> references. However, David's Rule #5 - "References considered harmful"
> How large? If it's 1000+ per node and big amount of nodes, jcr may not
> the best solution. But if you like some of the jcr, may consider
> hybrid solution with some other technical such as key/value store :)
If you are using JR 2, then you can use weak references instead of hard references which I think will mitigate some of the concerns associated with Rule #5. Have a look at EyeDB/MongoDB/HBase or similar for some very powerful data stores if JR is not the ideal solution for you. In general unless you are dealing with content (automatically index documents etc), JCR is unlikely to be the best solution.
Rakesh
Re: Practical limitations on the number of workspaces
Posted by Guo Du <mr...@gmail.com>.
On Thu, Dec 17, 2009 at 3:15 PM, Alan Chaney <al...@writingshow.com> wrote:
> (which is a 3D modelling system) requires a very large number of
> references. However, David's Rule #5 - "References considered harmful"
How large? If it's 1000+ per node and big amount of nodes, jcr may not
the best solution. But if you like some of the jcr, may consider
hybrid solution with some other technical such as key/value store :)
-Guo
Re: Practical limitations on the number of workspaces
Posted by Alan Chaney <al...@writingshow.com>.
Mat, Anibal and Bertrand
Thanks for your helpful comments - I looked through the DavidsModel and
also at the Jcrom page and found all your comments useful.
At this point my main area of concern is that my particular application
(which is a 3D modelling system) requires a very large number of
references. However, David's Rule #5 - "References considered harmful"
indicates that if I have versionable nodes which was actually one of the
principle reasons for using JR in the first place then I can use a guid
to link back to the original. This is aided by the fact that assets will
almost never be deleted from the system, so the issues of coping with
dangling references is not a major concern.
Regards
Alan Chaney
Anibal Sanchez wrote:
> I'm a newbie too... but reading the Davis Model... I think the trick is to
> understand how to work with weak structures.
>
> ORM in this context is not Hibernate/SQL. So It's better to be guided by
> Davis Model rules.
>
> At the end, we've implemented Jcrom as OM ... avoiding relationship, with a
> strong emphasis for contextual searches.
>
> Anibal
>
> On Wed, Dec 16, 2009 at 10:01 PM, Mat Lowery <ml...@pentaho.com> wrote:
>
>
>> Here's a page you might want to consult:
>>
>>
>> http://wiki.apache.org/jackrabbit/DavidsModel#Rule_.233:_Workspaces_are_for_clone.28.29.2C_merge.28.29_and_update.28.29
>> .
>>
>>
>> On Wed, 2009-12-16 at 16:00 -0800, Alan Chaney wrote:
>>
>>
>>> Hi
>>>
>>> I'm a complete newbie to using Jackrabbit. I'm designing a system in
>>> which I intend to manage a very large number of multimedia assets using
>>> JR workspaces as libraries. The library would have different node types
>>> depending upon the type of asset, which can be of various types, from a
>>> few lines of text to multi-megabyte binary files.
>>>
>>> Sorry if the following appears a dumb question, but I haven't yet really
>>> got very much experience with the practical side of JR. I've read both
>>> JSR 170 and JSR 283 but reading the specs is no substitute for hands on
>>> practical experience. Ideally I'd experiment, but sadly I'm under a bit
>>> of time pressure and so I'm hoping that people on this would be able to
>>> give me some advice.
>>>
>>> In our application users have their own "workbench" which is like a
>>> playground in which they can experiment with assets. It seems to me that:
>>>
>>> 1. I could implement the domain objects for the workbench and use an ORM
>>> to persist the relationships between this domain objects. These would
>>> contain references to nodes in the library which would be JR and this
>>> would provide the information required to deliver the data to the user.
>>>
>>> or
>>>
>>> 2. I could implement the "workbench" domain structure as jackrabbit
>>> nodes and have one workspace for each user. This may be 1000s of users
>>> (eventually). What are the practical limits on the number of jackrabbit
>>> workspaces - is it possible to have 100s or 1000s? The individual users
>>> workspaces would have references to some of the library items but the
>>> library would not have any references to the users items.
>>>
>>> Regards
>>>
>>> Alan Chaney
>>>
>>
>>
>
>
> !DSPAM:4b298915289212051017194!
>
>
Re: Practical limitations on the number of workspaces
Posted by Anibal Sanchez <an...@oquma.com>.
I'm a newbie too... but reading the Davis Model... I think the trick is to
understand how to work with weak structures.
ORM in this context is not Hibernate/SQL. So It's better to be guided by
Davis Model rules.
At the end, we've implemented Jcrom as OM ... avoiding relationship, with a
strong emphasis for contextual searches.
Anibal
On Wed, Dec 16, 2009 at 10:01 PM, Mat Lowery <ml...@pentaho.com> wrote:
> Here's a page you might want to consult:
>
>
> http://wiki.apache.org/jackrabbit/DavidsModel#Rule_.233:_Workspaces_are_for_clone.28.29.2C_merge.28.29_and_update.28.29
> .
>
>
> On Wed, 2009-12-16 at 16:00 -0800, Alan Chaney wrote:
>
> > Hi
> >
> > I'm a complete newbie to using Jackrabbit. I'm designing a system in
> > which I intend to manage a very large number of multimedia assets using
> > JR workspaces as libraries. The library would have different node types
> > depending upon the type of asset, which can be of various types, from a
> > few lines of text to multi-megabyte binary files.
> >
> > Sorry if the following appears a dumb question, but I haven't yet really
> > got very much experience with the practical side of JR. I've read both
> > JSR 170 and JSR 283 but reading the specs is no substitute for hands on
> > practical experience. Ideally I'd experiment, but sadly I'm under a bit
> > of time pressure and so I'm hoping that people on this would be able to
> > give me some advice.
> >
> > In our application users have their own "workbench" which is like a
> > playground in which they can experiment with assets. It seems to me that:
> >
> > 1. I could implement the domain objects for the workbench and use an ORM
> > to persist the relationships between this domain objects. These would
> > contain references to nodes in the library which would be JR and this
> > would provide the information required to deliver the data to the user.
> >
> > or
> >
> > 2. I could implement the "workbench" domain structure as jackrabbit
> > nodes and have one workspace for each user. This may be 1000s of users
> > (eventually). What are the practical limits on the number of jackrabbit
> > workspaces - is it possible to have 100s or 1000s? The individual users
> > workspaces would have references to some of the library items but the
> > library would not have any references to the users items.
> >
> > Regards
> >
> > Alan Chaney
>
>
>
Re: Practical limitations on the number of workspaces
Posted by Mat Lowery <ml...@pentaho.com>.
Here's a page you might want to consult:
http://wiki.apache.org/jackrabbit/DavidsModel#Rule_.233:_Workspaces_are_for_clone.28.29.2C_merge.28.29_and_update.28.29.
On Wed, 2009-12-16 at 16:00 -0800, Alan Chaney wrote:
> Hi
>
> I'm a complete newbie to using Jackrabbit. I'm designing a system in
> which I intend to manage a very large number of multimedia assets using
> JR workspaces as libraries. The library would have different node types
> depending upon the type of asset, which can be of various types, from a
> few lines of text to multi-megabyte binary files.
>
> Sorry if the following appears a dumb question, but I haven't yet really
> got very much experience with the practical side of JR. I've read both
> JSR 170 and JSR 283 but reading the specs is no substitute for hands on
> practical experience. Ideally I'd experiment, but sadly I'm under a bit
> of time pressure and so I'm hoping that people on this would be able to
> give me some advice.
>
> In our application users have their own "workbench" which is like a
> playground in which they can experiment with assets. It seems to me that:
>
> 1. I could implement the domain objects for the workbench and use an ORM
> to persist the relationships between this domain objects. These would
> contain references to nodes in the library which would be JR and this
> would provide the information required to deliver the data to the user.
>
> or
>
> 2. I could implement the "workbench" domain structure as jackrabbit
> nodes and have one workspace for each user. This may be 1000s of users
> (eventually). What are the practical limits on the number of jackrabbit
> workspaces - is it possible to have 100s or 1000s? The individual users
> workspaces would have references to some of the library items but the
> library would not have any references to the users items.
>
> Regards
>
> Alan Chaney
Re: Practical limitations on the number of workspaces
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Thu, Dec 17, 2009 at 1:00 AM, Alan Chaney <al...@writingshow.com> wrote:
> ...I'm a complete newbie to using Jackrabbit. I'm designing a system in which I
> intend to manage a very large number of multimedia assets using JR
> workspaces as libraries. The library would have different node types
> depending upon the type of asset, which can be of various types, from a few
> lines of text to multi-megabyte binary files...
Not sure if you need node types for that, my first impression is that
a property (a la mime-type or something) on the asset should be enough
to differentiate them. Or maybe a mixin, which can help in searches,
but different node types might be too constraining.
> ...1. I could implement the domain objects for the workbench and use an ORM...
> ...2. I could implement the "workbench" domain structure as jackrabbit nodes...
Option 2 sounds much better to me, the JCR API is clean and powerful
enough that you usually don't need to map it to objects, see recent
discussion about that at http://markmail.org/message/wmqggzrxwxearmyh
> ...and have one workspace for each user....
Probably not, a tree structure sounds more appropriate, maybe something like
/assets
/library
...library assets go here, chronological tree structure?
/users
/b
/bob
...bob's assets, chronological tree structure?
/bill
/f
/frank
/felix
etc..
In my opinion, thinking in terms of "how would I do that in a
filesystem" is often a good starting point with JCR, and you can then
add extra properties and nodes where needed for richer metadata than
what you'd get in a filesystem.
-Bertrand
This may be 1000s of users
> (eventually). What are the practical limits on the number of jackrabbit
> workspaces - is it possible to have 100s or 1000s? The individual users
> workspaces would have references to some of the library items but the
> library would not have any references to the users items.
>
> Regards
>
> Alan Chaney
>