From graffito-dev-return-570-apmail-incubator-graffito-dev-archive=www.apache.org@incubator.apache.org Tue Oct 04 11:08:32 2005 Return-Path: Delivered-To: apmail-incubator-graffito-dev-archive@www.apache.org Received: (qmail 45898 invoked from network); 4 Oct 2005 11:08:31 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 4 Oct 2005 11:08:31 -0000 Received: (qmail 83508 invoked by uid 500); 4 Oct 2005 11:08:31 -0000 Mailing-List: contact graffito-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: graffito-dev@incubator.apache.org Delivered-To: mailing list graffito-dev@incubator.apache.org Received: (qmail 83497 invoked by uid 99); 4 Oct 2005 11:08:31 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Oct 2005 04:08:31 -0700 X-ASF-Spam-Status: No, hits=0.3 required=10.0 tests=HTML_10_20,HTML_MESSAGE,RCVD_BY_IP,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of christophe.lombart@gmail.com designates 64.233.182.201 as permitted sender) Received: from [64.233.182.201] (HELO nproxy.gmail.com) (64.233.182.201) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Oct 2005 04:08:35 -0700 Received: by nproxy.gmail.com with SMTP id l37so220088nfc for ; Tue, 04 Oct 2005 04:08:08 -0700 (PDT) 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:references; b=H6nmOI/4USjWbKLqM74wlSjRn+PtmUMM4cbt8xeoazBNGh78y1w/kNyoYcTxKZSfXbRWHGGZ44igX1QvAU3n/xlwDoNCHsbfor7uegvEnF6gCA4AYiz3roTcH+HasRqsO0MlequFuvGsLanPX4GA+m3qBexvRaGsz8W9NtZR7Yo= Received: by 10.48.235.15 with SMTP id i15mr95512nfh; Tue, 04 Oct 2005 04:08:08 -0700 (PDT) Received: by 10.48.157.5 with HTTP; Tue, 4 Oct 2005 04:08:08 -0700 (PDT) Message-ID: <3b728ee90510040408g51ec61b6s37f051c20910cbc2@mail.gmail.com> Date: Tue, 4 Oct 2005 13:08:08 +0200 From: Christophe Lombart Reply-To: Christophe Lombart To: graffito-dev@incubator.apache.org Subject: Re: [jcr-mapping] PersistenceManager In-Reply-To: <514561512.20051004132929@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5973_12946701.1128424088295" References: <446671569.20051004112925@gmail.com> <3b728ee90510040211y593078bfk1e472d505e8a58e@mail.gmail.com> <1059667719.20051004123858@gmail.com> <3b728ee90510040307k61f34af7rcfff7914389e8e2f@mail.gmail.com> <514561512.20051004132929@gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_5973_12946701.1128424088295 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 10/4/05, Costin Leau wrote: >As I've said, considering that the developer has to open a session in >order to create the persistence manager it has a reference so he/she can >manually logoff. Session management is not the persistence manager >concern. Ok ! Now I understand you :-). The current code was build to make a prototype and discovering the JCR spec and now it is time to review all thinks. We have 2 possibitities : * Use distinct components : PersistenceManager and a JCR session object. In this case, we can forget all methods like exist, logout, ... in the PersistenceManager * Use only the PersistenceManager which encapsulate the JCR session. but in this case, we have to build a component manager/factory or other thinks which can initialise the PersistenceManager correctly. Is is a good summary of our discussion ? What do you like solution 1 or 2 ? >You mentioned something about OJB or Hibernate in the proposal. Take a >look at the Session interface (org.hibernate.Session) and trim it >down. >A simple interface would be: >add(Object) >remove(Object); >update(Object); >exists(Object); >Note I did not mention any path as this can be already present in the >XML mapping. If these basics are supported the path can be easily >added later. So, you force to have in each object, the attribute "path" - Correct ? >Try to do an insert and remove - a simple UC. >The current interface doesn't allow this and we are talking >about basic operations not collection findings, proxies or caching. >It's ... wierd to see discussion about 2nd level cache when basic >INSERT/UPDATE/DELETE methods do not exist even as signatures. Yep, some refactoring is needed there. Again, the code was used to build a prootype and now it is time to review all think. Christophe ------=_Part_5973_12946701.1128424088295--