« Return to Thread: Query closures for JDO 2.2
Re: Query closures for JDO 2.2
by Michael Bouschen-2
::
Rate this Message:
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 <wesley@...>:
>
>> +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@...> 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@...
>>> 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@...
Geschaeftsfuehrung: Anna-Kristin Proefrock
Sitz Berlin, Amtsgericht Charlottenburg, HRB 564 52
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@...>:
>
>> +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@...> 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@...
>>> 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@...
Geschaeftsfuehrung: Anna-Kristin Proefrock
Sitz Berlin, Amtsgericht Charlottenburg, HRB 564 52
« Return to Thread: Query closures for JDO 2.2
| Free embeddable forum powered by Nabble | Forum Help |
