Return-Path: Delivered-To: apmail-maven-continuum-dev-archive@www.apache.org Received: (qmail 25751 invoked from network); 22 Feb 2008 10:07:10 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 22 Feb 2008 10:07:10 -0000 Received: (qmail 26231 invoked by uid 500); 22 Feb 2008 10:07:05 -0000 Delivered-To: apmail-maven-continuum-dev-archive@maven.apache.org Received: (qmail 26200 invoked by uid 500); 22 Feb 2008 10:07:05 -0000 Mailing-List: contact continuum-dev-help@maven.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: continuum-dev@maven.apache.org Delivered-To: mailing list continuum-dev@maven.apache.org Received: (qmail 26179 invoked by uid 99); 22 Feb 2008 10:07:05 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Feb 2008 02:07:05 -0800 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of emmanuel.venisse@gmail.com designates 64.233.184.227 as permitted sender) Received: from [64.233.184.227] (HELO wr-out-0506.google.com) (64.233.184.227) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Feb 2008 10:06:32 +0000 Received: by wr-out-0506.google.com with SMTP id 55so517346wri.2 for ; Fri, 22 Feb 2008 02:06:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=R12NXlcGncFSWDQ5qI8H11A3L2TyimJAf4qQKxVgZS0=; b=LWBWTZboowTpxBlDKCvmfoDWmgEwDD1JdRS5lbXsHZqoFqgnNoby4u6yeF3wctluvBkAUG/STVWM2RyfE8VgYhHXO+A8kXZJwKXu48Jp2c6+F5kHcLZio0VnyKUcu/h8M49F1G1vQl553zOsue39sUiGagPeiP2vvtLX5YXDeEU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=SsnaSI22vcEoDjE9F6l8YFdW4WZY/WOSCWbWVAatXlcbk5b2S8Q2Sxu+/Ni/3QCotmByBaYn4N7qFcbTiGRSA58WvJd7REDpLZV8CaJTMvbkZLdWJl89wWnmmXVRA9Gsiua57PqOAcFHmjmdD0ga8dNIA8Qb22/XnR69WY4b8OY= Received: by 10.115.22.1 with SMTP id z1mr1341450wai.48.1203674799604; Fri, 22 Feb 2008 02:06:39 -0800 (PST) Received: by 10.114.73.6 with HTTP; Fri, 22 Feb 2008 02:06:39 -0800 (PST) Message-ID: Date: Fri, 22 Feb 2008 11:06:39 +0100 From: "Emmanuel Venisse" To: continuum-dev@maven.apache.org, rahul.thakur.xdev@gmail.com Subject: Re: ContinuumStore refactoring In-Reply-To: <47BE99CB.7080607@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_9455_23840020.1203674799600" References: <5d3354e30802211754y54625a60la19c64142c58e6bc@mail.gmail.com> <47BE99CB.7080607@gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_9455_23840020.1203674799600 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Fri, Feb 22, 2008 at 10:45 AM, Rahul Thakur 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 > ------=_Part_9455_23840020.1203674799600--