You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Pinaki Poddar (JIRA)" <ji...@apache.org> on 2009/03/31 19:06:50 UTC
[jira] Created: (OPENJPA-1014) Build weakly-typed Criteria API
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-M1
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.
[jira] Updated: (OPENJPA-1014) Build weakly-typed Criteria API
Posted by "Donald Woods (JIRA)" <ji...@apache.org>.
[ 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.