« Return to Thread: Subquery specification update
Re: Subquery specification update
by Craig L Russell
::
Rate this Message:
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:
> 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
>
>> -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.
>>>
>
>
> --
> 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
>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!
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:
> 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
>
>> -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.
>>>
>
>
> --
> 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
>
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@...
P.S. A good JDO? O, Gasp!
smime.p7s (3K) « Return to Thread: Subquery specification update
| Free embeddable forum powered by Nabble | Forum Help |
