Any Suggestions for Implementing Global Revision/Change Set

[Aloke Agarwal <ag...@yahoo.com>]

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:

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.


 Thanks
Aloke

Re: Any Suggestions for Implementing Global Revision/Change Set

[Paul J DeCoursey <pa...@decoursey.net>]

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.