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)