[
https://issues.apache.org/jira/browse/JDO-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018116#comment-13018116
]
Matthew T. Adams commented on JDO-617:
--------------------------------------
After discussing on the conf call Fri Apr 9, we considered the separation of
the query definition from the persistence manager connected to which the query
definition is executed. It became evident that there is a separation of
concerns between the definition or criteria of the query and the PM against
which it should execute.
Instead of a TypesafeQuery<T>, perhaps the class could have a name that
reflects the fact that it's a query definition, like
TypesafeQueryDefinition<T>, TypesafeQueryCriteria<T>, or, considering that
we're in Java and type safety is inherent, I'd move to drop the prefix
"Typesafe" from the name and go with just something like QueryCritieria<T>.
The currently proposed "Q" classes could be called XxxCriteria ("TeamCriteria"
in this example).
It should also be abled to be obtained by the PMF or the PM. New PMF methods:
// proposed new methods on PMF
1. <T> QueryCriteria<T> newQueryCriteria(Class<T> clazz);
2. Various overloads to execute the given QueryCriteria using the PM given by
PMF.getPersistenceManagerProxy()
New methods could be added to PM to allow for the execution of the query using
that PM:
// methods on PM
1. <T> QueryCriteria<T> newQueryCriteria(Class<T> clazz);
2. Various overloads to execute the given QueryCriteria using this PM.
I see two options for methods that execute these queries. First, only put the
execution methods (execute, update, delete) on the PM to keep the number of
overloads down, or second, provide overloaded execution methods (execute,
update, delete) on the QueryCriteria classes, one set of which takes a PM and
delegates to its appropriate execution method, and another set of which does
not take a PM and delegates to the PM given by
PMF.getPersistenceManagerProxy(). The choice of which option comes down to how
many overloaded methods there would be.
Additionally, if such overloaded execution methods are provided on the
QueryCriteria<T> class, should the ones taking no PM execute against the PM
returned from PM.getPersistenceManagerProxy() or, if the QueryCriteria was
obtained from a PM, the PM from which it came?
> JDOQL : Bulk Update and Delete Operations
> -----------------------------------------
>
> Key: JDO-617
> URL: https://issues.apache.org/jira/browse/JDO-617
> Project: JDO
> Issue Type: New Feature
> Reporter: Eric SULTAN
>
> It would be usefull that the JDO Query Langage could do some UPDATE and
> DELETE on Persistent Object like this :
> UPDATE [<candidate-class>] SET item1=<newValue>, item2=<newValue> [WHERE
> <filter>]
> The new_value specified for an update operation must be compatible in type
> with the state-field to
> which it is assigned.
> Bulk Update must modify the value of the version column and refresh Level1
> and Level2 cache.
> DELETE FROM [<candidate-class>] [WHERE <filter>]
> By default Bulk Delete is appy on the specified class and its subclasses and
> doesn't do cascade delete.
> A keyword like CASCADE must be set if we want to does a cascade delete :
> DELETE CASCADE FROM [<candidate-class>] [WHERE <filter>]
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
