Thanks for the suggestion that solved our issue. Our time went down by 2 order of magnitude.
Thanks Aloke ----- Original Message ---- From: Paul J DeCoursey <[EMAIL PROTECTED]> To: [email protected] 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. http://music.yahoo.com/unlimited
