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

Donald Woods updated OPENJPA-1014:
----------------------------------

    Affects Version/s:     (was: 2.0.0)
        Fix Version/s:     (was: 2.0.0-M4)
                           (was: 2.0.0)

> Build weakly-typed Criteria API
> -------------------------------
>
>                 Key: OPENJPA-1014
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-1014
>             Project: OpenJPA
>          Issue Type: New Feature
>          Components: jpa
>            Reporter: Pinaki Poddar
>            Assignee: Pinaki Poddar
>             Fix For: 2.0.0-M3
>
>
> JPA 2.0 has introduced specification for weakly-typed (I prefer 
> relaxed-typed) dynamic query construction a.k.a untypesafe Criteria API. The 
> earlier draft version of JPA described a relaxed-typed dynamic query which 
> had already been implemented in OpenJPA. However, this API had a short life 
> span and now no more endorsed by the spec. Given that the API has been 
> reasonably  appreciated by the user community with its ease of use and we 
> already have an implementation for it, that implementation is refactored into 
> a OpenJPA specific 'Dynamic Query' API. The approach followed to implement 
> this 'Dynamic Query' was completely decoupled from OpenJPA query 
> infrastructure. The output was a pure JPQL string and that was the input to 
> OpenJPA query. The approach had its advantage of a clean design at the cost 
> of paying for parsing the JPQL query string again.
> While it is possible to revert to that strategy for new relaxed-typed 
> Criteria API but such strategy will force us to very dissimilar approaches 
> (one for the strict-typed and the other for the relaxed-typed). Instead what 
> I am proposing is to implement relaxed-type API on the basis of 
> strongly-typed API implementation. Given that the strongly-typed API will 
> require a meta-model, I feel we can devise a way for the relaxed-typed API to 
> resolve as soon as possible the user input (String) to a proper type (Class). 
> This will keep the implementation uniform.
>  

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

Reply via email to