Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 46158 invoked from network); 8 Mar 2010 13:38:32 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 8 Mar 2010 13:38:32 -0000 Received: (qmail 78736 invoked by uid 500); 8 Mar 2010 13:38:08 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 78693 invoked by uid 500); 8 Mar 2010 13:38:08 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 78686 invoked by uid 99); 8 Mar 2010 13:38:08 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 08 Mar 2010 13:38:08 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of tmueller@day.com designates 207.126.148.88 as permitted sender) Received: from [207.126.148.88] (HELO eu3sys201aog102.obsmtp.com) (207.126.148.88) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 08 Mar 2010 13:37:59 +0000 Received: from source ([74.125.82.176]) by eu3sys201aob102.postini.com ([207.126.154.11]) with SMTP ID DSNKS5T9oPUxYYLZPj9P9z0Rdg7D3TxqWGfy@postini.com; Mon, 08 Mar 2010 13:37:39 UTC Received: by wyb38 with SMTP id 38so2673771wyb.7 for ; Mon, 08 Mar 2010 05:37:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.89.12 with SMTP id b12mr2640778wef.93.1268055456741; Mon, 08 Mar 2010 05:37:36 -0800 (PST) In-Reply-To: References: <510143ac1002170906n3ca54d32k6e6b60e15922c03d@mail.gmail.com> <91f3b2651002172343h707fcb0eub8c962716f5d2711@mail.gmail.com> Date: Mon, 8 Mar 2010 14:37:36 +0100 Message-ID: <91f3b2651003080537s73836109o3f23e9887ffb0948@mail.gmail.com> Subject: Re: [jr3] MVCC From: =?ISO-8859-1?Q?Thomas_M=FCller?= To: dev@jackrabbit.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org 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