Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Message-ID: <753070400.1243971787637.JavaMail.jira@brutus>
Date: Tue, 2 Jun 2009 12:43:07 -0700 (PDT)
From: "Jeremy Bauer (JIRA)" <jira@apache.org>
To: dev@openjpa.apache.org
Subject: [jira] Updated: (OPENJPA-1013) Build strictly-typed Criteria API
In-Reply-To: <2133264374.1238517770430.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/OPENJPA-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeremy Bauer updated OPENJPA-1013:
----------------------------------

    Parent Issue: OPENJPA-1105  (was: OPENJPA-1052)

> Build strictly-typed Criteria API
> ---------------------------------
>
>                 Key: OPENJPA-1013
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-1013
>             Project: OpenJPA
>          Issue Type: Sub-task
>            Reporter: Pinaki Poddar
>            Assignee: Pinaki Poddar
>             Fix For: 2.0.0-M1
>
>   Original Estimate: 1344h
>  Remaining Estimate: 1344h
>
> JPA 2.0 has introduced specification for strictly-typed dynamic query construction a.k.a Criteria API. The design challenge to support this feature comes from the following
> 1. how to leverage existing OpenJPA query infrastructure?
> 2. the type-strictness is supported on the basis of a instantiated meta-model -- this is new for OpenJPA query infrastructure. Should we introduce more type-strictness in OpenJPA query infrastructure or not? 
> The design goals (currently)
> 1. select current design pattern rather than some arbitrary hack to bridge existing OpenJPA query infrastructure and JPA 2.0 type-strict Criteria. Possibly it is Adapter pattern.
> 2. Do not change OpenJPA query infrastructure with more type-strictness (it is not type-free after all). Rather inject type information from the artifacts that implement new Criteria API into OpenJPA query artifacts.
> The implementation strategy:
> 1. Prototype the approach first.
> 2. Solidify a design that can be boiler plated (ok, almost) for numerous supported query expression and clauses. Then delegate construction of these parts.   

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.