db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthew T. Adams (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JDO-617) JDOQL : Bulk Update and Delete Operations
Date Sun, 10 Apr 2011 17:44:05 GMT

    [ 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

Mime
View raw message