openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Donald Woods (JIRA)" <j...@apache.org>
Subject [jira] Updated: (OPENJPA-1014) Build weakly-typed Criteria API
Date Tue, 22 Sep 2009 19:14:16 GMT

     [ 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.


Mime
View raw message