jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Chaney <a...@writingshow.com>
Subject Re: Practical limitations on the number of workspaces
Date Thu, 17 Dec 2009 15:15:26 GMT
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 <mlowery@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!
>
>   


Mime
View raw message