What about a CVS Store? Michael Oliver CTO/Matrix Intermedia 7391 S. Bullrider Ave. Tucson, AZ 85747 Office (520)574-1150 Cell (518)378-6154
Martin Holz said: > > Hello Peter, > > "Nevermann, Dr., Peter" <[EMAIL PROTECTED]> writes: > >> Good point! Currently, I have no idea how to overcome this problem in >> principle, i.e. by distributing the content of /history onto multiple >> subdirectories, but I will keep thinking about it. >> >> It doesn't really solve the problem ... but anyway: you currently can >> have a separate history folder for each configured store, e.g.: >> /history/store1 >> /history/store2 >> >> Is maybe some optimization in the JDBCDescriptorsStore implementation >> possible? > > I guess, there is plenty of room for optimization, but it does not solve > the O(n) behavior. I belive this is a store independent problem. The > size of the /history node grows and nodes are always store in one > piece. You can't save only the changes. > > >> > From: Martin Holz [mailto:[EMAIL PROTECTED] >> > has anybody experience in versioning and a large number of documents >> (10,000 to 100,000)? I did a VERSION call on 8000 documents. The >> first >> > calls where fast, but this last took almost 1 minute (3 GHz Pentium, >> plenty of free memory, JDBCDescriptorsStore with Postgres). >> > While I did >> > not yet dive into the code, it seems to be obvious, where the >> bottleneck is. >> > >> > All version history resources are stored as children of the same >> node '/history'. So every time a new version history is created, >> there is a call to DescriptorsStore.storeObject for the node >> /history. >> > However this node grows linear with the number of version histories. >> So does the time to store it. >> > >> > For the JDBCDescriptorsStore this means deleting N-1 rows from the >> table children and inserting N rows, if the Nth version >> > history is created. >> > >> > Without looking into details, I think, the answer would be to >> > change the URIs of history from a linear to something tree like. >> > >> > E.g /history/1234 => /history/1/2/4/h4. >> > >> > Is somebody working on this problem? Some pointers, where to start? > > I am currently testing my own version of UriHandler, which > creates a directory tree as descriped above. So far it looks promising. > I will report back soon. > > Is there any code outside UriHandler and > DeltavConstants.I_INITIAL_HISTORY_NAME, that makes > assumptions over the history uris ? > > > -- > Martin Holz <[EMAIL PROTECTED]> > > Softwareentwicklung / Vernetztes Studium - Chemie > FIZ CHEMIE Berlin > Franklinstrasse 11 > D-10587 Berlin > > > --------------------------------------------------------------------- To > unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
