From dev-return-28750-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Tue Feb 03 19:44:18 2009 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 8428 invoked from network); 3 Feb 2009 19:44:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 3 Feb 2009 19:44:17 -0000 Received: (qmail 43854 invoked by uid 500); 3 Feb 2009 19:44:17 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 43815 invoked by uid 500); 3 Feb 2009 19:44:17 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 43806 invoked by uid 99); 3 Feb 2009 19:44:17 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Feb 2009 11:44:17 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [69.145.82.195] (HELO skunk.mtbrook.bozemanpass.com) (69.145.82.195) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Feb 2009 19:44:09 +0000 Received: from [69.145.82.247] (unknown [69.145.82.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by skunk.mtbrook.bozemanpass.com (Postfix) with ESMTP id AAE7855829D for ; Tue, 3 Feb 2009 11:43:48 -0800 (PST) Message-ID: <49889E6E.80108@bozemanpass.com> Date: Tue, 03 Feb 2009 12:43:42 -0700 From: David Boreham MIME-Version: 1.0 To: Apache Directory Developers List Subject: Re: [DRS] thoughts about implementation References: <4985EEB3.7070406@gmail.com> <1cbc90c10902020928j469ceb10ied5daf450da18529@mail.gmail.com> <498898BC.6060307@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Hi, just a voice from the trenches, having done this a few times and made some mistakes: Do not invent a new kind of database for the change log. Instead use the one you already have for entries, with some appropriate indexing enhancements to support the change log semantics required. i.e. each change log record is in fact an entry. (there may be a way to do it where the change log data is actually stored in the entries themselves, and absolutely no additional records are required, but this seems to take an extra high level of cunning to pull off). But, please don't make work for yourself by doubling the kinds of database you have. Two databases also makes it hard to ensure transactional integrity between the main db and the change log (which is important to have).