|
Home > Archive > Apache JDO Project > December 2007 > Query closures for JDO 2.2
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Query closures for JDO 2.2
|
|
| Craig L Russell 2007-12-01, 1:11 pm |
| | |
| Wesley Biggs 2007-12-01, 7:11 pm |
| +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!
>
>
>
| |
| Michael Bouschen 2007-12-09, 7:11 pm |
| 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@cacas.org>:
>
>
>
>
--
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
| |
| Erik Bengtson 2007-12-10, 1:11 pm |
| VGhlIGltcGxlbWVudGF0aW9uIGNhbiBkbyB0aGUg
bmVjZXNzYXJ5IGluIDEgb3IgbW9yZSBzdGF0
ZW1lbnRzIGFzIHlvdSBzYWlkLiANCg0KLS0gICBC
bGFja0JlcnJ5riBmcm9tIE1vYmlzdGFyICAg
IC0tLQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQ0KRnJvbTogTWljaGFlbCBCb3VzY2hl
biA8bWJvLnRlY2hAc3ByZWUuZGU+DQoNCkRhdGU6
IFN1biwgMDkgRGVjIDIwMDcgMjI6MjI6Mjcg
DQpUbzpBcGFjaGUgSkRPIHByb2plY3QgPGpkby1k
ZXZAZGIuYXBhY2hlLm9yZz4NCkNjOkpETyBF
eHBlcnQgR3JvdXAgPGpkby1leHBlcnRzLWV4dEBz
dW4uY29tPg0KU3ViamVjdDogUmU6IFF1ZXJ5
IGNsb3N1cmVzIGZvciBKRE8gMi4yDQoNCg0KSGks
DQoNCmR1cmluZyB0aGUgSkRPIFRDSyBjb25m
ZXJlbmNlIGNhbGwgbGFzdCBGcmlkYXkgYSBxdWVz
dGlvbiBjYW1lIHVwIGFib3V0IA0KcG9zc2li
bGUgcmVzdHJpY3Rpb25zIG9uIHN1Y2ggYSBwZXJm
b3JtIGJsb2NrLiBTUUwgZG9lcyBub3QgYWxs
b3cgDQptdWx0aXBsZSB0YWJsZXMgaW4gdGhlIEZS
T00gY2xhdXNlIG9mIGFuIFVQREFURSBzdGF0
ZW1lbnQuIFNvIHNob3VsZCB3ZSANCnB1dCByZXN0
cmljdGlvbnMgb24gSkRPUUwgdG8gYWxsb3cg
YSAxLTEgbWFwcGluZyB0byBTUUw/ IElzc3VlcyB0byBiZSANCmNvbnNpZGVyZWQ6IHVw
ZGF0ZSBv
ZiBmaWVsZHMgbWFwcGVkIHRvIGEgc2Vjb25kYXJ5
IHRhYmxlLCByZWxhdGlvbnNoaXAgDQp1cGRh
dGVzIGFuZCB1c2Ugb2YgdmFyaWFibGVzIHRvIHVw
ZGF0ZSByZWxhdGVkIGluc3RhbmNlcy4gSG93
ZXZlciwgDQptdWx0aXBsZSBTUUwgc3RhdGVtZW50
cyBhbmQvb3Igc3VicXVlcmllcyBtaWdodCBi
ZSBuZWVkZWQgYW55d2F5IGZvciANCmluaGVyaXRh
bmNlIGFuZCBleGlzdGVudGlhbCBxdWVyaWVz
IChtZWFuaW5nIHJlbGF0aW9uc2hpcCBuYXZpZ2F0
aW9uIGluIA0KdGhlIFdIRVJFIGNsYXVzZSku
DQoNCkFub3RoZXIgcXVlc3Rpb24gaXMgYWJvdXQg
dGhlIHRlcm0gInBlcmZvcm0iLiBJdCByZWlu
Zm9yY2VzIHRoZSBpZGVhIA0KdGhhdCB5b3Ugc2Vs
ZWN0IGEgbnVtYmVyIG9mIEphdmEgaW5zdGFu
Y2VzIGFuZCBwZXJmb3JtIHNvbWUgYmxvY2sgYWN0
aW9uIA0Kb24gdGhlbS4gSG93ZXZlciwgcGVv
cGxlIG1pZ2h0IGV4cGVjdCB0byB1c2UgdGhlIHdv
cmQgInVwZGF0ZSIgZm9yIHN1Y2ggDQphbiBv
cGVyYXRpb24uDQoNCldoYXQgZG8geW91IHRoaW5r
Pw0KDQpSZWdhcmRzIE1pY2hhZWwNCg0KPiAr
MTogYnVsayB1cGRhdGUgaXMgZWZmaWNpZW50IGZl
YXR1cmUuDQo+DQo+IDIwMDcvMTIvMSwgV2Vz
bGV5IEJpZ2dzIDx3ZXNsZXlAY2FjYXMub3JnPjoN
Cj4gICANCj4+ICsxLiAgSSBsaWtlIHRoZSAi
cGVyZm9ybSIgdGVybTsgaXQgcmVpbmZvcmNlcyB0
aGUgYWJzdHJhY3Rpb24gb2YNCj4+ICJzZWxl
Y3QgdGhlc2UgaW50byBKYXZhLCB0aGVuIHBlcmZv
cm0gdGhpcyBhY3Rpb24iIC0tIGkuZS4geW91
IGdldA0KPj4gc2lkZSBlZmZlY3RzLg0KPj4NCj4+
IFdlcw0KPj4NCj4+IFAuUy4gWW91ciBjb2Rl
IGV4YW1wbGUgbmVlZHMgMSArIDpwZXJjZW50IGlu
c3RlYWQgb2YgMS4wNi4NCj4+DQo+PiBPbiAw
MS8xMi8yMDA3LCBDcmFpZyBMIFJ1c3NlbGwgPENy
YWlnLlJ1c3NlbGxAc3VuLmNvbT4gd3JvdGU6
DQo+PiAgICAgDQo+Pj4gQXMgeW91IGtub3csIEkn
bSBub3QgZm9uZCBvZiB0aGUgbm9uLW9iamVj
dCBzdHlsZSBvZiBxdWVyeSB1cGRhdGUsDQo+Pj4g
YW5kIHRoZXJlIGFyZSBjYXNlcyB3aGVyZSB5
b3Ugd2FudCB0byBkbyBhIGJ1bGsgdXBkYXRlIGVm
ZmljaWVudGx5IGluDQo+Pj4gdGhlIGRhdGFz
dG9yZSwgYnV0IFNRTCBqdXN0IGRvZXNuJ3QgY2Fw
dHVyZSB0aGUgb2JqZWN0IG1hcHBpbmcgdGhh
dA0KPj4+IGlzIHVzZWQgaW4gdGhlIHJlc3Qgb2Yg
dGhlIGFwcGxpY2F0aW9uLg0KPj4+DQo+Pj4g
U28gd2hhdCBhYm91dCBkZWZpbmluZyBhIHF1ZXJ5
IGNsb3N1cmUsIHRoYXQgaXMsIGRlY2xhcmUg
YSBzZXQgb2YNCj4+PiBzdGF0ZW1lbnRzIHRoYXQg
aXMgZXhlY3V0ZWQgZm9yIGVhY2ggcXVhbGlm
eWluZyBpbnN0YW5jZSB0aGF0DQo+Pj4gc2F0aXNm
aWVzIHRoZSBmaWx0ZXIuDQo+Pj4NCj4+PiBU
aGlzIGNvdWxkIGV4ZWN1dGUgaW4gbWVtb3J5IGZv
ciBtZW1vcnkgY29sbGVjdGlvbnMsIG9yIGlu
IHRoZQ0KPj4+IGRhdGFzdG9yZSBmb3Igbm9uLWlu
c3RhbnRpYXRlZCBjb2xsZWN0aW9ucy4gRm9y
IHBvcnRhYmlsaXR5IHdlIG5lZWQNCj4+PiB0byBk
ZWZpbmUgdGhlIGNsb3N1cmUgaW4gdGVybXMg
dGhhdCBjYW4gYmUgbWFwcGVkIGRpcmVjdGx5IHRv
IFNRTC4NCj4+Pg0KPj4+IEZvciBleGFtcGxl
LA0KPj4+DQo+Pj4gUEVSRk9STSBzYWxhcnkgKj0g
MS4gKyA6cGVyY2VudDsgbGFzdFNhbGFyeUFk
anVzdG1lbnQgPSA6ZGF0ZSBGUk9NDQo+Pj4gRW1w
bG95ZWUgV0hFUkUgcmF0aW5nID09IDpyYXRp
bmcNCj4+Pg0KPj4+IFF1ZXJ5IHEgPSBwbS5uZXdR
dWVyeShFbXBsb3llZSwgInJhdGluZyA+IDpy
YXRpbmciKTsNCj4+PiBxLnNldFBlcmZvcm0oInNh
bGFyeSAqPSAxLjA2OyBsYXN0U2FsYXJ5QWRq
dXN0bWVudCA9IDpkYXRlIik7DQo+Pj4gcS5leGVj
dXRlKC4wNiwgbmV3IERhdGUoKSwgNyk7DQo+
Pj4NCj4+Pg0KPj4+IENyYWlnIFJ1c3NlbGwNCj4+
PiBBcmNoaXRlY3QsIFN1biBKYXZhIEVudGVy
cHJpc2UgU3lzdGVtIGh0dHA6Ly9qYXZhLnN1bi5j
b20vcHJvZHVjdHMvamRvDQo+Pj4gNDA4IDI3
Ni01NjM4IG1haWx0bzpDcmFpZy5SdXNzZWxsQHN1
bi5jb20NCj4+PiBQLlMuIEEgZ29vZCBKRE8/
IE8sIEdhc3AhDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4g
ICAgICAgDQo+PiAgICAgDQo+DQo+DQo+ICAg
DQoNCg0KLS0gDQpUZWNoQFNwcmVlIEVuZ2luZWVy
aW5nIEdtYkggIFRlbC46ICs0OS8oMCkzMC8y
MzUgNTIwLTMzDQpCdWVsb3dzdHIuIDY2ICAgICAg
ICAgICAgICAgIEZheC46ICs0OS8oMCkzMC8y
MTcgNTIwLTEyDQoxMDc4MyBCZXJsaW4gICAgICAg
ICAgICAgICAgIG1haWx0bzptYm8udGVjaEBz
cHJlZS5kZSANCiANCkdlc2NoYWVmdHNmdWVocnVu
ZzogQW5uYS1LcmlzdGluIFByb2Vmcm9jaw0K
U2l0eiBCZXJsaW4sIEFtdHNnZXJpY2h0IENoYXJs
b3R0ZW5idXJnLCBIUkIgNTY0IDUyDQoNCg0K
| |
| Christiaan 2007-12-11, 7:11 pm |
|
Hi,
since you are calling this "perform" would there also be a possibility to
somehow incorporate my copy by query feature request?
http://www.nabble.com/Feature-reque...to13855888.html
As a side and practical note, I am working in a domain where many objects
are involved, so for performance and memory issues it would really benefit
from these "bulk" operations. The delete-by-query was a real must have in
that regard. However, in the field I am working, I doubt whether
update-by-query would be of the same added value for two reasons:
1) updating in our domain often involves some complex logic, eg. values
should be updated based on values in other (children) objects and other
factors. Could this be expressed in the closure? (and if it is, wouldn't
that be too much going against the OO paradigm)
2) our experience is that these update operations can be done really quick
within reasonable memory usage due to fetchgroups (you only load what you
need) and fetchsize (having the right value really speeds up iterating).
On the other hand, as mentioned in the copy-by-query request, copying can be
a very time and memory consuming task, since both original and copy need to
be completely in memory, while most of the time there is no need to load
them into memory.
kind regards,
Christiaan
--
View this message in context: http://www.nabble.com/Query-closure...1p14282910.html
Sent from the JDO - Development mailing list archive at Nabble.com.
|
|
|
|
|