The implementation can do the necessary in 1 or more statements as you said.
-- BlackBerry® from Mobistar --- -----Original Message----- From: Michael Bouschen <[EMAIL PROTECTED]> Date: Sun, 09 Dec 2007 22:22:27 To:Apache JDO project <[email protected]> Cc:JDO Expert Group <[EMAIL PROTECTED]> Subject: Re: Query closures for JDO 2.2 Hi, during the JDO TCK conference call last Friday a question came up about possible restrictions on such a perform block. SQL does not allow multiple tables in the FROM clause of an UPDATE statement. So should we put restrictions on JDOQL to allow a 1-1 mapping to SQL? Issues to be considered: update of fields mapped to a secondary table, relationship updates and use of variables to update related instances. However, multiple SQL statements and/or subqueries might be needed anyway for inheritance and existential queries (meaning relationship navigation in the WHERE clause). Another question is about the term "perform". It reinforces the idea that you select a number of Java instances and perform some block action on them. However, people might expect to use the word "update" for such an operation. What do you think? Regards Michael > +1: bulk update is efficient feature. > > 2007/12/1, Wesley Biggs <[EMAIL PROTECTED]>: > >> +1. I like the "perform" term; it reinforces the abstraction of >> "select these into Java, then perform this action" -- i.e. you get >> side effects. >> >> Wes >> >> P.S. Your code example needs 1 + :percent instead of 1.06. >> >> On 01/12/2007, Craig L Russell <[EMAIL PROTECTED]> wrote: >> >>> As you know, I'm not fond of the non-object style of query update, >>> and there are cases where you want to do a bulk update efficiently in >>> the datastore, but SQL just doesn't capture the object mapping that >>> is used in the rest of the application. >>> >>> So what about defining a query closure, that is, declare a set of >>> statements that is executed for each qualifying instance that >>> satisfies the filter. >>> >>> This could execute in memory for memory collections, or in the >>> datastore for non-instantiated collections. For portability we need >>> to define the closure in terms that can be mapped directly to SQL. >>> >>> For example, >>> >>> PERFORM salary *= 1. + :percent; lastSalaryAdjustment = :date FROM >>> Employee WHERE rating == :rating >>> >>> Query q = pm.newQuery(Employee, "rating > :rating"); >>> q.setPerform("salary *= 1.06; lastSalaryAdjustment = :date"); >>> q.execute(.06, new Date(), 7); >>> >>> >>> Craig Russell >>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo >>> 408 276-5638 mailto:[EMAIL PROTECTED] >>> P.S. A good JDO? O, Gasp! >>> >>> >>> >>> >> > > > -- [EMAIL PROTECTED] Engineering GmbH Tel.: +49/(0)30/235 520-33 Buelowstr. 66 Fax.: +49/(0)30/217 520-12 10783 Berlin mailto:[EMAIL PROTECTED] Geschaeftsfuehrung: Anna-Kristin Proefrock Sitz Berlin, Amtsgericht Charlottenburg, HRB 564 52
