Hi, >> Relational databases don't usually persist all (intermediate) >> versions, just the committed version. I don't think that copy-on-read >> is a good idea. If we use append-only storage, in theory all old >> versions are available, but indexing those is problematic. > > not necessarily. the current implementation in jackrabbit already > supports quite some of these features. you can keep an index reader > open while the index is updated, which basically gives you read-only > multi-versioning. it would even be possible to go back in time by > keeping old commit points. basic support for this is already > implemented.
I didn't mean the Lucene index. I mean indexing the node position in an append only storage (where is the node x version y stored in the persistence manager). Currently Lucene is not used for that (and it shouldn't). For append-only storage, probably the the easiest way to index old versions is to persist a new root node for each transaction (like CouchDB does). In each node, store the direct pointer (absolute or relative file id / position) to all child nodes. In that case, no separate index is required. However, I don't think we should *require* that all persistence managers work like this. We should allow append-only storage, but not require it. Regards, Thomas
