|
Home > Archive > Apache JDO Project > October 2007 > Subquery specification update
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 |
Subquery specification update
|
|
| Craig L Russell 2007-10-24, 7:11 pm |
| | |
| Christiaan 2007-10-25, 7:11 am |
|
Hi Craig,
the examples are very informative. I must say that I find the description
for candidateCollectionExpression
"The candidateCollectionExpression is the expression using tokens from
this query that represent the candidates over which the subquery is
evaluated. "
a little bit cryptic (I actually find the paramater name more descriptive
than the description). Especially "tokens from this query" (is tokens a
common word for this and may be it should be stressed that this query is the
outer query?) and "over which the subquery is evaluated", but may be this is
needed for the spec.
Anyway, do I understand it correctly that it is the same as:
.....
sub.setFilter(":departmentEmployees.contains(this)");
Query q = pm.newQuery(Employee.class);
q.setFilter("this.weeklyHours > averageWeeklyhours");
q.addSubquery(sub, "double averageWeeklyhours", null,
"this.department.employees");
kind regards,
Christiaan
--
View this message in context: http://www.nabble.com/Subquery-spec....html#a13405438
Sent from the JDO - Development mailing list archive at Nabble.com.
| |
| Matthew Adams 2007-10-25, 1:11 pm |
| I agree that the candidateCollectionExpression description is a bit
cryptic.
Boy, it's been a long time since I thought about subqueries. Can we
also provide single-string versions of the examples? That would be
helpful.
-matthew
On Oct 25, 2007, at 5:07 AM, Christiaan wrote:
>
> Hi Craig,
> the examples are very informative. I must say that I find the
> description
> for candidateCollectionExpression
> "The candidateCollectionExpression is the expression using tokens from
> this query that represent the candidates over which the subquery is
> evaluated. "
> a little bit cryptic (I actually find the paramater name more
> descriptive
> than the description). Especially "tokens from this query" (is
> tokens a
> common word for this and may be it should be stressed that this
> query is the
> outer query?) and "over which the subquery is evaluated", but may
> be this is
> needed for the spec.
>
> Anyway, do I understand it correctly that it is the same as:
> ....
> sub.setFilter(":departmentEmployees.contains(this)");
> Query q = pm.newQuery(Employee.class);
> q.setFilter("this.weeklyHours > averageWeeklyhours");
> q.addSubquery(sub, "double averageWeeklyhours", null,
> "this.department.employees");
>
> kind regards,
> Christiaan
> --
> View this message in context: http://www.nabble.com/Subquery-
> specification-update-tf4686785.html#a13405438
> Sent from the JDO - Development mailing list archive at Nabble.com.
>
| |
| Michael Bouschen 2007-10-25, 1:11 pm |
| Hi Matthew, hi Christiaan,
> I agree that the candidateCollectionExpression description is a bit
> cryptic.
Do you have an idea for a better description? The reason to include
something like "tokens from this query" is that we have to define the
scope for identifiers used in the candidateCollectionExpression. So in
"this.department.employees" this denotes the candidate instance of the
outer query and NOT of the subquery.
>
> Boy, it's been a long time since I thought about subqueries. Can we
> also provide single-string versions of the examples? That would be
> helpful.
Do you mean add single string JDOQL of the examples to the spec or
provide them for this email discussion? I agree it would be useful to
add them to the spec. If you are just interested for right now:
- employees who work more than the average of all employees
SELECT FROM Employee WHERE this.weeklyhours > (SELECT AVG(e.weeklyhours)
FROM Employee e)
- employees who work more than the average of their department employees
SELECT FROM Employee WHERE this.weeklyhours > (SELECT AVG(e.weeklyhours)
FROM this.department.employees e)
- employees who work more than the average of the employees in their
department having the same manager:
SELECT FROM Employee WHERE this.weeklyhours >
(SELECT AVG(e.weeklyhours) FROM Employee e WHERE e.manager ==
this.manager)
Christiaan,
yes, I think the query code you added to your email returns the same result.
Regards Michael
[vbcol=seagreen]
> -matthew
>
> On Oct 25, 2007, at 5:07 AM, Christiaan wrote:
>
--
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
| |
| Craig L Russell 2007-10-25, 1:11 pm |
| | |
| Michael Bouschen 2007-10-25, 1:11 pm |
| Hi Craig,
I assume you are referring to the example given by Christiaan, right?
sub.setFilter(":departmentEmployees.contains(this)");
Query q = pm.newQuery(Employee.class);
q.setFilter("this.weeklyHours > averageWeeklyhours");
q.addSubquery(sub, "double averageWeeklyhours", null, "this.department.employees");
The sample code does not use the parameter in the FROM clause. Instead
it uses the entire extent as the candidates of the subquery and
restricts the instances using the parameter in the filter of the subquery.
I think reading the single string JDOQL helps understanding the query,
so I agree t would be better to move all the subquery examples down to
the examples section.
Regards Michael
> Currently, parameters are only specified to work in the result,
> filter, ordering, grouping, or range parts of a query, not in the FROM
> part. This is in both the single string version (from
> CandidateClassName ExcludeClause opt) and API version where the
> setCandidates takes either Extent or Collection, not parameter name.
>
> I'm not necessarily opposed to adding the ability to use parameters as
> the candidate collection, but I'd like to hear more details as to how
> a parameter can be used as a candidate collection, and from the
> implementation engineers to see if this change could be done.
>
> The only problem I have with including single string JDOQL to the
> examples is that it would be before the single string JDOQL topic was
> introduced. Would it be better to move all the subquery examples down
> to the examples section?
>
> Craig
>
> On Oct 25, 2007, at 8:37 AM, Michael Bouschen wrote:
>
>
> 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
| |
| Craig L Russell 2007-10-25, 1:11 pm |
| |
|
|
|
|