From jackrabbit-dev-return-367-apmail-incubator-jackrabbit-dev-archive=www.apache.org@incubator.apache.org Thu Nov 18 11:52:02 2004 Return-Path: Delivered-To: apmail-incubator-jackrabbit-dev-archive@www.apache.org Received: (qmail 75986 invoked from network); 18 Nov 2004 11:52:02 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 18 Nov 2004 11:52:02 -0000 Received: (qmail 44354 invoked by uid 500); 18 Nov 2004 11:52:00 -0000 Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jackrabbit-dev@incubator.apache.org Delivered-To: mailing list jackrabbit-dev@incubator.apache.org Received: (qmail 44325 invoked by uid 99); 18 Nov 2004 11:52:00 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=RCVD_BY_IP,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: domain of david.nuescheler@gmail.com designates 64.233.170.206 as permitted sender) Received: from [64.233.170.206] (HELO rproxy.gmail.com) (64.233.170.206) by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 18 Nov 2004 03:51:57 -0800 Received: by rproxy.gmail.com with SMTP id i8so1119916rne for ; Thu, 18 Nov 2004 03:51:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=ed95VUlG9vlNB2kJMn9CkQQfci3hRBWXhpAiMnKbgAWk+Z2+uFwkv8kB4KNWQviOwUmfiWhW0zU/N4kMajsLaxYFHSUcejUF2DBjNdZmXM69gM8iwdnHLZDoJqMza2PO6H+xW7J0COf1sbOuRhYpYAyX1oMuHDnIEV5FP0w9iGM= Received: by 10.38.83.67 with SMTP id g67mr501127rnb; Thu, 18 Nov 2004 03:51:50 -0800 (PST) Received: by 10.38.164.46 with HTTP; Thu, 18 Nov 2004 03:51:50 -0800 (PST) Message-ID: Date: Thu, 18 Nov 2004 12:51:50 +0100 From: David Nuescheler Reply-To: david.nuescheler@day.com To: jackrabbit-dev@incubator.apache.org Subject: Re: Jackrabbit DBPersistenceManager In-Reply-To: <018301c4c95f$fba42050$6601000a@MYAGENT102> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <018301c4c95f$fba42050$6601000a@MYAGENT102> X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N hi wolfgang, thanks a lot for contributing jdbc pm (persistence manager). after taking a first look at the code that you submitted personally i would like to have at least the following questions answered or issues resolved before i personally could vote +1 on the contribution. i am convinced that all of those issues/questions can be easily fixed/answered: ------- first of all there seems an administrational issue that as far as i understand with respect to the fact that the contribution is a seperable contribution, we would need a CLA on file from you. for a patch this would not be necessary (please anybody correct me if i am wrong) --- what is the benefit of the additional abstraction using dao, especially since the generic (abstract) datamodel is mandated by the implementation of the pm, shouldn't repository and jsr-170 provide such abstraction already? personally, i would probably favour a more direct access to the db. --- should the empty class "MyHashmap" be removed or renamed? as far as i understand it may be useful for future extensibility however the classname doesn't inspire a clear intention ;) ? --- since you submitted a 15mb package of the entire modified svn tree we have problems finding out what and why exactly was added / modified (do you think it would be possible to just send us a zip of your additions?) --- what is the thought behind creating a dom to pass arguments from one java method to another? was this just a quick hack or is that a pattern? ---- to me it looks like your pm does not support multivalue properties, references or binary values (am i wrong?). what concerns me about that is that those are important functional pieces of a repository. stefan hacked up one afternoon quite a while ago a prototype for a database driven pm, that was able to support the full functional spectrum of a repository and being much more lightweight at the same time. we are currently having internal discussion if we should commit that as an example on how we see an implementation of a jdbc pm that is very lightweight, fast and simple. obviously it requires a very abstract generic datamodel in the rdbms too... ---- generally, i believe that the earlier proposed changes to the pm api, with respect to allow a pm to operate in a transactional fashion, as you suggested, will have quite a big impact. so i think it maybe still be worth waiting a little bit, until the pm api has "settled again" ;) ------- this is probably not a complete list of questions/comments but it could be a starting point. another question that i have for the entire jackrabbit-dev-community: since it seems like a number of people started to implement jackrabbit pms and other extensions that maybe are not finished, should we create a section of the svn tree dedicated to experimental code in general? some sort of sandbox or proposals. experiences from other projects? additionally, since everybody received wolfgangs contribution, i would like to encourage everybody to use it and share their experiences. regards, david