jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aloke Agarwal <agarwal_al...@yahoo.com>
Subject Any Suggestions for Implementing Global Revision/Change Set
Date Fri, 03 Nov 2006 00:19:43 GMT

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:

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.
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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message