You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Michael Bouschen <mb...@spree.de> on 2008/10/21 23:32:33 UTC

Methods in the result of an JDOQL query

Hi,

the current spec is not explicit on using methods in the query result 
expression, e.g.
  "select this.phoneNumbers.size() from Employee",
   "select this.phoneNumbers.get("home") from Employee",
   "select this.firstName.substring(1,4) from Employee"

It looks like a good idea supporting these kind of queries, but the 
question is whether there are any issues from the JDO implemention point 
of view. The related JIRA isse is 
https://issues.apache.org/jira/browse/JDO-580

Comments?

Regards Michael

-- 
*Michael Bouschen*
*Prokurist*

akquinet tech@spree GmbH
Tempelhofer Ufer 23-24, D-10963 Berlin
Bülowstr. 66, D-10783 Berlin

Fon:   +49 30 235 520-33
Fax:   +49 30 217 520-12
Email: michael.bouschen@akquinet.de
Url:    www.akquinet.de <http://www.akquinet.de>

akquinet tech@spree GmbH, Berlin
Geschäftsführung: Prof. Dr. Christian Roth, Hendrik Saly, Martin Weber
Amtsgericht Berlin-Charlottenburg HRB 86780
USt.-Id. Nr.: DE 225 964 680

Re: Methods in the result of an JDOQL query

Posted by Andy Jefferson <an...@datanucleus.org>.
> the current spec is not explicit on using methods in the query result
> expression, e.g.
>   "select this.phoneNumbers.size() from Employee",
>    "select this.phoneNumbers.get("home") from Employee",
>    "select this.firstName.substring(1,4) from Employee"
>
> It looks like a good idea supporting these kind of queries, but the
> question is whether there are any issues from the JDO implemention point
> of view. The related JIRA isse is
> https://issues.apache.org/jira/browse/JDO-580
>
> Comments?

Hi Michael,

supporting methods in the SELECT clause is of course fine in principal, and at 
the very least the spec needs to be explicit. In practice some methods would 
be harder to support than others. Thinking in an RDBMS context, things like 
String/Date methods usually have a related SQL function hence no issue. 
Collection.size() could equate to (SELECT COUNT(*) FROM ...) and some RDBMS 
(or some versions of some RDBMS) maybe won't be supporting that (subqueries).
Similarly Collection.contains(...) when the argument to contains is something 
other than a non-PC object, etc.

There may be other implementation issues to be found by whoever offers their 
time to implement them, 



-- 
Andy  (DataNucleus - http://www.datanucleus.org)