Author: kwsutter
Date: Fri Sep 20 20:12:13 2013
New Revision: 1525124
URL: http://svn.apache.org/r1525124
Log:
save for posterity...
Modified:
openjpa/site/trunk/content/jpa-2.1-tasks.mdtext
Modified: openjpa/site/trunk/content/jpa-2.1-tasks.mdtext
URL:
http://svn.apache.org/viewvc/openjpa/site/trunk/content/jpa-2.1-tasks.mdtext?rev=1525124&r1=1525123&r2=1525124&view=diff
==============================================================================
--- openjpa/site/trunk/content/jpa-2.1-tasks.mdtext (original)
+++ openjpa/site/trunk/content/jpa-2.1-tasks.mdtext Fri Sep 20 20:12:13 2013
@@ -38,12 +38,57 @@ Reference(s) </th></tr>
<tr><td class="border"> <font color="red">Not Started</font> </td><td
class="border"> <a
href="https://issues.apache.org/jira/browse/OPENJPA-????";>OPENJPA-????</a>
- </td><td class="border"> High </td><td class="border"> Add ON condition to
JPQL query. Will require BNF change (see jpql.jjt). Can ripple across the
codebase. </td><td class="border"> ??? </td><td class="border">
+ </td><td class="border"> High </td><td class="border"> Add ON condition to
JPQL query.
+<p>Will require BNF change (see jpql.jjt). Can ripple across the codebase.
</td><td class="border"> ??? </td><td class="border">
4.4.5.2 </td></tr>
<tr><td class="border"> <font color="red">Not Started</font> </td><td
class="border"> <a
href="https://issues.apache.org/jira/browse/OPENJPA-????";>OPENJPA-????</a>
</td><td class="border"> High </td><td class="border"> Downcast relation
paths with TREAT operator in JPQL queries. Will require BNF change. The BNF
changes will be non-trivial as TREAT can appear as a path component e.g.
p.TREAT(p.items as Book).pageCount.
-JPQLEpressionBuilder will require change to process the treated path. The
downstream changes on building the appropriate expression will not be a heavy
task as the current kernel expressions support the notion of implicit
types.</td><td class="border"> ??? </td><td class="border">
+<p>JPQLEpressionBuilder will require change to process the treated path. The
downstream changes on building the appropriate expression will not be a heavy
task as the current kernel expressions support the notion of implicit
types.</td><td class="border"> ??? </td><td class="border">
4.4.9 </td></tr>
+<tr><td class="border"> <font color="red">Not Started</font> </td><td
class="border"> <a
href="https://issues.apache.org/jira/browse/OPENJPA-????";>OPENJPA-????</a>
+ </td><td class="border"> Low </td><td class="border"> Use database function
or user-defined function with FUNCTION operator in JPQL queries The support for
this feature exists. The task is mainly to parse (JPQLEpressionBuilder) and
connect to the appropriate kernel expression.
+ </td><td class="border"> ??? </td><td class="border">
+4.6.17.3 </td></tr>
+<tr><td class="border"> <font color="red">Not Started</font> </td><td
class="border"> <a
href="https://issues.apache.org/jira/browse/OPENJPA-????";>OPENJPA-????</a>
+ </td><td class="border"> Low </td><td class="border"> Object construction in
mapping results from native SQL query The support for this feature exists in
ResultShape object.
+ </td><td class="border"> ??? </td><td class="border">
+3.10.16.2.2 </td></tr>
+<tr><td class="border"> <font color="red">Not Started</font> </td><td
class="border"> <a
href="https://issues.apache.org/jira/browse/OPENJPA-????";>OPENJPA-????</a>
+ </td><td class="border"> Medium </td><td class="border"> Add ON condition to
Criteria Query The on() function is to be added to each derivation of Join
separately because of generic signature of the method.
+ </td><td class="border"> ??? </td><td class="border">
+4.4.5.2 </td></tr>
+<tr><td class="border"> <font color="red">Not Started</font> </td><td
class="border"> <a
href="https://issues.apache.org/jira/browse/OPENJPA-????";>OPENJPA-????</a>
+ </td><td class="border"> Medium </td><td class="border"> Add TREAT operator
in Criteria query Each derivation of Path interface will require a downcast
construct e.g. a class like PathImpl$Treated because the return type of the
classes that implement path has generic type signature in OpenJPA
implementation. A downcast (or treated) path must have a different generic
signature for compile-time type checking.
+ </td><td class="border"> ??? </td><td class="border">
+6.3 </td></tr>
+<tr><td class="border"> <font color="red">Not Started</font> </td><td
class="border"> <a
href="https://issues.apache.org/jira/browse/OPENJPA-????";>OPENJPA-????</a>
+ </td><td class="border"> Medium </td><td class="border"> Delete via Criteria
query The design challenge for this task is to reuse the existing code for
query portion of existing implementation.
+ </td><td class="border"> ??? </td><td class="border">
+6.3.6 </td></tr>
+<tr><td class="border"> <font color="red">Not Started</font> </td><td
class="border"> <a
href="https://issues.apache.org/jira/browse/OPENJPA-????";>OPENJPA-????</a>
+ </td><td class="border"> Medium </td><td class="border"> Update via Criteria
query Same comment as the above task. The good news is that the refactoring has
been done.
+ </td><td class="border"> ??? </td><td class="border">
+6.3.5 </td></tr>
+<tr><td class="border"> <font color="red">Not Started</font> </td><td
class="border"> <a
href="https://issues.apache.org/jira/browse/OPENJPA-????";>OPENJPA-????</a>
+ </td><td class="border"> Very High </td><td class="border"> Invoke Stored
Procedure. The basic support for CallableStatement exists in OpenJPA. However,
this feature is going to impact several aspects of current query execution
model. A stored procedure can result into multiple types of result sets while
the current execution model assumes that a query returns a single type of
result. It is unclear at this point how best to handle such multiplicity. Also
parameter processing (always a rather weak/heuristic aspect of OpenJPA)
requires extension.
+ </td><td class="border"> ??? </td><td class="border">
+3.10.17 </td></tr>
+<tr><td class="border"> <font color="red">Not Started</font> </td><td
class="border"> <a
href="https://issues.apache.org/jira/browse/OPENJPA-????";>OPENJPA-????</a>
+ </td><td class="border"> ??? </td><td class="border"> Bulk update of the
members of an embeddable collection.
+ </td><td class="border"> ??? </td><td class="border">
+ </td></tr>
+<tr><td class="border"> <font color="red">Not Started</font> </td><td
class="border"> <a
href="https://issues.apache.org/jira/browse/OPENJPA-????";>OPENJPA-????</a>
+ </td><td class="border"> Medium </td><td class="border"> Context Dependency
Injection via Entity Listeners
+ </td><td class="border"> ??? </td><td class="border">
+3.5 </td></tr>
+<tr><td class="border"> <font color="red">Not Started</font> </td><td
class="border"> <a
href="https://issues.apache.org/jira/browse/OPENJPA-????";>OPENJPA-????</a>
+ </td><td class="border"> Medium </td><td class="border"> Create EntityManager
with SynchronizationType.UNSYNCHRONIZED. Unsynchorized context requires to be
explicitly joined to a JTA transaction, as opposed to SYNCHRONIZED contexts
that are automatically joined to a JTA transaction if available.
+<p>If an unsynchronized context is not joined to a transaction, queries with
pessimistic locks, bulk update or delete queries will throw the
TransactionRequiredException.
+<p>The context propgation rules differ and certain restrictions apply when the
context is unsynchronized.
+<p>A new method of EntityManager affirms if a context has joined a transaction.
+<p>It is recommended that a non-JTA datasource be specified for use by the
persistence provider for a persistence context of type
SynchronizationType.UNSYNCHRONIZED that has not been joined to a JTA
transaction in order to alleviate the risk of integrating uncommitted changes
into the persistence context in the event that the transaction is later rolled
back.
+ </td><td class="border"> ??? </td><td class="border">
+7.6.1 </td></tr>
</table>
\ No newline at end of file
