db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Bengtson" <e...@jpox.org>
Subject Re: Query closures for JDO 2.2
Date Mon, 10 Dec 2007 07:43:55 GMT
The implementation can do the necessary in 1 or more statements as you said. 

--   BlackBerry® from Mobistar    ---

-----Original Message-----
From: Michael Bouschen <mbo.tech@spree.de>

Date: Sun, 09 Dec 2007 22:22:27 
To:Apache JDO project <jdo-dev@db.apache.org>
Cc:JDO Expert Group <jdo-experts-ext@sun.com>
Subject: Re: Query closures for JDO 2.2


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 <wesley@cacas.org>:
>> +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 <Craig.Russell@sun.com> 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:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!

Tech@Spree Engineering GmbH  Tel.: +49/(0)30/235 520-33
Buelowstr. 66                Fax.: +49/(0)30/217 520-12
10783 Berlin                 mailto:mbo.tech@spree.de 
Geschaeftsfuehrung: Anna-Kristin Proefrock
Sitz Berlin, Amtsgericht Charlottenburg, HRB 564 52

View raw message