Return-Path: Delivered-To: apmail-continuum-dev-archive@www.apache.org Received: (qmail 579 invoked from network); 2 Apr 2008 03:59:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 2 Apr 2008 03:59:26 -0000 Received: (qmail 61572 invoked by uid 500); 2 Apr 2008 03:59:26 -0000 Delivered-To: apmail-continuum-dev-archive@continuum.apache.org Received: (qmail 61548 invoked by uid 500); 2 Apr 2008 03:59:26 -0000 Mailing-List: contact dev-help@continuum.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@continuum.apache.org Delivered-To: mailing list dev@continuum.apache.org Received: (qmail 61539 invoked by uid 99); 2 Apr 2008 03:59:26 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Apr 2008 20:59:26 -0700 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: 124.108.96.113 is neither permitted nor denied by domain of rahul.thakur.xdev@gmail.com) Received: from [124.108.96.113] (HELO rel106.mail.aue.yahoo.com) (124.108.96.113) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 02 Apr 2008 03:58:32 +0000 Received: (qmail 88228 invoked by uid 1000); 2 Apr 2008 03:58:49 -0000 Received: from 124.108.96.70 by rel106.mail.aue.yahoo.com with SMTP; Tue, 01 Apr 2008 20:58:49 -0700 Received: (qmail 71745 invoked from network); 2 Apr 2008 03:58:49 -0000 Received: from unknown (HELO ?192.168.103.153?) (rahul.thakur@xtra.co.nz@203.193.119.196 with plain) by smtp101.tnz.mail.aue.yahoo.com with SMTP; 2 Apr 2008 03:58:49 -0000 X-YMail-OSG: xElMIRAVM1lipz_mFaajAsUnGSqzbOsOIio.5wTNIp8pG7kLRvEDTBRsm_CH7H7g8g-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <47F3046F.3010604@gmail.com> Date: Wed, 02 Apr 2008 16:58:39 +1300 From: Rahul Thakur User-Agent: Thunderbird 3.0a1pre (Windows/2008032502) MIME-Version: 1.0 To: dev@continuum.apache.org Subject: Re: Some continuum-jpa branch updates References: <5d3354e30712091504n5e5bc3e5g27823312f3124f16@mail.gmail.com> <9FEB08F7-2D69-4F1A-9FAF-66881251AF7E@apache.org> In-Reply-To: <9FEB08F7-2D69-4F1A-9FAF-66881251AF7E@apache.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org I am happy with the refactorings to the Store API; but IIRC Emmanuel mentioned was that he would put in some code to reflect his ideas on how he sees the Store API to shape up (w.r.t Criteria API). So basically, from my end (and if everyone agrees): 1) Need to bring over the Store API changes from JPA branch. 2) Bring over Entity classes; Annotations will need some review and updates. Cheers, Rahul Brett Porter wrote: > Rahul, > > What's the status of this work? Are you thinking of phasing it in to > trunk, based on findings from the experiments, or something else? > > Cheers, > Brett > > On 10/12/2007, at 10:04 AM, Rahul Thakur wrote: > >> Hi All, >> >> Scribbling some quick notes on some of the toying around I have been >> doing with OpenJPA, Generics etc on the continuum-jpa branch[1]: >> >> 1) Use JPA for persistence >> Motivation behind this has been to investigate how this compares to >> JPOX/JDO for managing the model - both in terms on performance and >> ease of use (Store APIs). Continuum model classes are annotated with >> JPA annotations on the branch. However, this needs a review as there >> are some elements (for example 'configuration' typed as Map) that I am >> not sure yet how to persist yet. The provider used is OpenJPA [2]. >> >> 2) Refactorings to Store interface >> Main motivation has been to keep the core Store interface lean and >> mean (read extensible). The Store interface[3] now has 4 methods: >> lookup() >> save() >> delete() >> query() >> >> The lookup(), save() and delete() act on single model Entity, while >> query() will filter and obtain matching Entities from the underlying >> database based on the Query specified. Query implementations control >> how a resulting JPQL gets constructed and which matching entities get >> pulled, and can be easily extended. >> >> To preserve compatibility with the existing Store interface, we can >> mimick the existing ContinuumStore interface operations by having a >> facade that can prepare requisite queries and delegate to a Store >> instance. >> >> 3) Misc. >> There are a few I am investigating: >> 1) Spring/Guice under the hood. >> 2) JUnit 4.4 (and Hamcrest library) >> , but these are still in early stages. >> >> I am keen to get a feedback on what others think. >> >> Cheers, >> >> Rahul >> >> >> [1] - >> http://svn.apache.org/repos/asf/maven/continuum/branches/continuum-jpa/ >> >> [2] - http://openjpa.apache.org/ >> >> [3] - >> http://svn.apache.org/repos/asf/maven/continuum/branches/continuum-jpa/continuum-model-jpa/src/main/java/org/apache/maven/continuum/store/api/Store.java >> > > -- > Brett Porter > brett@apache.org > http://blogs.exist.com/bporter/ > >