jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aloke Agarwal <agarwal_al...@yahoo.com>
Subject Re: Any Suggestions for Implementing Global Revision/Change Set
Date Thu, 09 Nov 2006 21:41:22 GMT
Thanks for the suggestion that solved our issue. Our time went down by 2 order of magnitude.


----- Original Message ----
From: Paul J DeCoursey <paul@decoursey.net>
To: users@jackrabbit.apache.org
Sent: Thursday, November 2, 2006 5:50:32 PM
Subject: Re: Any Suggestions for Implementing Global Revision/Change Set

Aloke Agarwal wrote:
> Hi,
> We are evaluation jackrabbit for one of our project. The project is to provide an XML
repository with the following functional requirements:
> 1.  Ability to have different document types to be stored in repository. (For example:
/toys/action/x.xml, book/x etc).
> 2. All the documents stored are all xml documents which needs to be querieable through
xquery (for example get all book where book.author etc).
> 3. Ability to store all documents as versionable.
> 4. Ability to retrieve documents based on global revision. The concept of global revision
is similar to "subversion" concept where a user can submit x number of documents and the system
returns a unique id back to the user. The user can then use this id to get "any" document
in the repository at that point in time not just what he/she checked in.
> Based on the above requirement we were evaluating jackrabbit and have an initial implementation
of "globalrevision" and xpath like capability. Our solution is as follows:
> We have root node called:
Why does each node need the globalrevisionid? why not just keep that ID 
on the root node?

> root (mix:versionable)
>     - child1
>         -property called (globalrevisionid)
>     - child 2
>         -property called (globalrevisionid)
>     - child 3
>         -property called (globalrevisionid)
> globalrevisionroot (mix: versionable)
>     - globalrevision1
>     - globalrevision2
> So every time there is a commit we save the nodes that are checked in and then walk the
whole tree to set the property called "globalrevisionid" on all the nodes under root at that
point in time. 
> Our problem is as follows:
> 1. The performance is really bad with a repository with 500 nodes it takes 10 minutes
after every save to put this globalrevision property on all the nodes.
If you move the revisionid to a single node then this shouldn't be an issue.
> 2. It does a checkout/set property/checkin in all the root nodes and hence creates an
unneccesary revision in the repository.
> 3. The lucene search indexing takes a long time everytime
> Has anyway tried implementing something similar to what we are trying to do?. Is there
any better way to do what we are trying to do in JCR.
>  Thanks
> Aloke

I think that have 1 instance of the revisionid will solve all your issues.

Yahoo! Music Unlimited
Access over 1 million songs.
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message