From dev-return-6917-apmail-continuum-dev-archive=continuum.apache.org@continuum.apache.org Tue Apr 29 03:58:23 2008 Return-Path: Delivered-To: apmail-continuum-dev-archive@www.apache.org Received: (qmail 92002 invoked from network); 29 Apr 2008 03:58:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 29 Apr 2008 03:58:23 -0000 Received: (qmail 76153 invoked by uid 500); 29 Apr 2008 03:58:25 -0000 Delivered-To: apmail-continuum-dev-archive@continuum.apache.org Received: (qmail 76126 invoked by uid 500); 29 Apr 2008 03:58:25 -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 76115 invoked by uid 500); 29 Apr 2008 03:58:25 -0000 Delivered-To: apmail-maven-continuum-dev@maven.apache.org Received: (qmail 76112 invoked by uid 99); 29 Apr 2008 03:58:24 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 28 Apr 2008 20:58:24 -0700 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.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; Tue, 29 Apr 2008 03:57:38 +0000 Received: (qmail 29861 invoked by uid 1000); 29 Apr 2008 03:57:50 -0000 Received: from 124.108.96.70 by rel106.mail.aue.yahoo.com with SMTP; Mon, 28 Apr 2008 20:57:50 -0700 Received: (qmail 87477 invoked from network); 29 Apr 2008 03:57:50 -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; 29 Apr 2008 03:57:49 -0000 X-YMail-OSG: Kbd.QikVM1mumrQZ09y__V8ZInqMJbb0nEjHLN5xL9PhB7dUZF1yDvJ3IagHfUCYuQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48169CBF.5030406@gmail.com> Date: Tue, 29 Apr 2008 15:57:51 +1200 From: Rahul Thakur User-Agent: Thunderbird 3.0a1pre (Windows/2008041703) MIME-Version: 1.0 To: continuum-dev@maven.apache.org Subject: Re: ContinuumStore refactoring References: <5d3354e30802211754y54625a60la19c64142c58e6bc@mail.gmail.com> <47BE99CB.7080607@gmail.com> <5d3354e30802271907x4541ba39g17a8a9b1cad0ba97@mail.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 Emmanuel, Just wondering if you hacked some samples? :-) Cheers, Rahul Emmanuel Venisse wrote: > I'll create some examples asap. > > Emmanuel > > On Thu, Feb 28, 2008 at 4:07 AM, Rahul Thakur > wrote: > >> Hi, >> >> Some code using a couple of Entities as examples would be nice :-) >> >> I still think the API would be verbose. >> >> Thanks, >> Rahul >> >> >> On Fri, Feb 22, 2008 at 11:06 PM, Emmanuel Venisse >> wrote: >>> >>> >>> >>> On Fri, Feb 22, 2008 at 10:45 AM, Rahul Thakur< >> rahul.thakur.xdev@gmail.com> >>> wrote: >>>> >>>>>> 2) Criteria vs Named Queries: I am not convinced (yet) that Named >>>>>> queries are the way to go. I did some digging around, they are >> indeed >>>>>> best practices for JPA but I think the decision merits other >>>>>> consideration(s). I still believe the Criteria Queries will help us >>>>>> define a cleaner Store interface. >>>>>> >>>>> >>>>> I'm always in favor of named queries. >>>>> An other point about them that I haven't explain in previous threads >> (I >>>>> think) is that with named queries, it is possible to modify queries >>>>> externally with xml files so if with a DB we have some performance >>> issues, >>>>> it will be possible to override queries by a modified JPQL query or >> a >>> native >>>>> query. >>>>> >>>> How do you see the refactored ContinuumStore interface using Named >>>> Queries? I suspect it will be just as verbose again. >>> I don't want to see a new time a big class for the store part. it must >> be >>> splitted in few domains. >>> All named queries related to Project would be defined in the Project >> class, >>> all named queries related to ProjectGroup would be defined in the >>> ProjectGroup class... >>> >>> And we can add some more classes for particular results that aren't >> entities >>> objects (we won't have a lot) >>> >>> With this, all concerns are separated and linked to a specific entity. >> Easy >>> to code, easy to read, easy to understand. It's my opinion. >>> >>>> Sorry, still not convinced ;-) >>> I hope you are now ;-) >>> >>> Emmanuel >>>> >>>> Rahul >>>> >>> >