Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jdo-dev@db.apache.org
Date: Sun, 10 Apr 2011 17:44:05 +0000 (UTC)
From: "Matthew T. Adams (JIRA)" <jira@apache.org>
To: jdo-dev@db.apache.org
Message-ID: 
 <953337088.47954.1302457445761.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (JDO-617) JDOQL : Bulk Update and Delete
 Operations
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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