Subquery specification update

[Craig L Russell]

Here's the specification update for addSubquery that was missing from  
the previous version.

Subqueries
void addSubQuery (Query subquery, String variableDeclaration,
        String candidateCollectionExpression);
This method adds a subquery to this Query. A subquery is composed as  
a Query and subsequently attached to a different Query by calling  
this method. The Query parameter instance is unmodified as a result  
of the addSubquery or subsequent execution of the outer Query. Only  
some of the query parts are copied for use as the subquery. The parts  
copied include the candidate class, filter, parameter declarations,  
variable declarations, imports, ordering specification, uniqueness,  
result specification, and grouping specification. The association  
with a PersistenceManager, the candidate collection, result class,  
limits on size, and number of skipped instances are not used.

The variableDeclaration is the name of the variable containing the  
results of the subquery execution. If the same value of  
variableDeclaration is used to add multpile subqueries, the subquery  
replaces the previous subquery for the same variableDeclaration. If  
the subquery parameter is null, the variableDeclaration is unset,  
effectively making the variable named in the variableDeclaration  
unbound.

The candidateCollectionExpression is the expression using tokens from  
this query that represent the candidates over which the subquery is  
evaluated.

For example, to find employees who work more than the average of all  
employees,
Query sub = pm.newQuery(Employee.class);
sub.setResult("avg(this.weeklyhours)");
Query q = pm.newQuery(Employee.class);
q.setFilter("this.weeklyHours > averageWeeklyhours");
q.addSubquery(sub, "double averageWeeklyhours", null);

Correlated subqueries
A correlated subquery is a subquery which contains references to  
fields in the outer query. If the correlation can be expressed as a  
restriction of the candidate collection of the subquery, no  
parameters are needed.

For example, to find employees who work more than the average of  
their department employees:
Query sub = pm.newQuery(Employee.class);
sub.setResult("avg(this.weeklyhours)");
Query q = pm.newQuery(Employee.class);
q.setFilter("this.weeklyhours> averageWeeklyhours");
q.addSubquery(sub, "double averageWeeklyhours",  
"this.department.employees");

If the correlation cannot be expressed as a restriction of the  
candidate collection, the correlation is expressed as one or more  
parameters in the subquery which are bound to expressions of the  
outer query.
void addSubquery(String variableDeclaration,
        Query subquery, String candidateCollectionExpr, String parameter);
void addSubquery(String variableDeclaration,
        Query subquery, String candidateCollectionExpr, String[] parameters);
void addSubquery(String variableDeclaration,
        Query subquery, String candidateCollectionExpr, Map parameters);
The parameters parameter in the above methods binds parameters in the  
subquery to expressions in the outer query.

For example, to find employees who work more than the average of the  
employees in their department having the same manager:
Query sub = pm.newQuery(Employee.class);
sub.setResult("avg(this.weeklyhours)");
sub.setFilter("this.manager == :manager");
Query q = pm.newQuery(Employee.class);
q.setFilter("this.weeklyHours > averageWeeklyhours");
q.addSubquery(sub, "double averageWeeklyhours",  
"this.department.employees", "this.manager");
The parameter in the subquery “:manager” is bound to the expression  
“this.manager” in the context of the outer query.

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!

[Christiaan]

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

[Matthew T. Adams-2]

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-2]

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.: [phone]
Buelowstr. 66                Fax.: [phone]
10783 Berlin                 mailto:mbo.tech@...
 
Geschaeftsfuehrung: Anna-Kristin Proefrock
Sitz Berlin, Amtsgericht Charlottenburg, HRB 564 52

[Craig L Russell]

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.: [phone]
> Buelowstr. 66                Fax.: [phone]
> 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!

[Michael Bouschen-2]

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:
>
>> 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.: [phone]
>> Buelowstr. 66                Fax.: [phone]
>> 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!
>

--
Tech@Spree Engineering GmbH  Tel.: [phone]
Buelowstr. 66                Fax.: [phone]
10783 Berlin                 mailto:mbo.tech@...
 
Geschaeftsfuehrung: Anna-Kristin Proefrock
Sitz Berlin, Amtsgericht Charlottenburg, HRB 564 52

[Craig L Russell]

Hi Michael,

On Oct 25, 2007, at 9:20 AM, Michael Bouschen wrote:

> Hi Craig,
>
> I assume you are referring to the example given by Christiaan, right?

Yes.

>
> 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.

Yes, I now understand this. Thanks for clarifying.
>
> 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

I have another draft version for review here. I've tried to clarify  
the candidate collection binding and added some rules about  
validating parameters of the addSubquery. I've also changed  
addSubQuery to addSubquery (case change) to be consistent.

Subqueries
void addSubquery (Query subquery, String variableDeclaration,
        String candidateCollectionExpression);
This method adds a subquery to this Query. A subquery is composed as  
a Query and subsequently attached to a different Query (the outer  
Query) by calling this method. The String parameters are trimmed of  
white space.
The Query parameter instance is unmodified as a result of the  
addSubquery or subsequent execution of the outer Query. Only some of  
the parameter query parts are copied for use as the subquery. The  
parts copied include the candidate class, filter, parameter  
declarations, variable declarations, imports, ordering specification,  
uniqueness, result specification, and grouping specification. The  
association with a PersistenceManager, the candidate collection or  
extent, result class, and range limits are not used.
The variableDeclaration parameter is the name of the variable  
containing the results of the subquery execution. If the same value  
of variableDeclaration is used to add multpile subqueries, the  
subquery replaces the previous subquery for the same named variable.  
If the subquery parameter is null, the variable is unset, effectively  
making the variable named in the variableDeclaration unbound. If the  
trimmed value is the empty String, or the parameter is null, then  
JDOUserException is thrown.
The candidateCollectionExpression is the expression from the outer  
query that represent the candidates over which the subquery is  
evaluated. If the trimmed value is the empty String, or the parameter  
is null, then the candidate collection is the extent of the candidate  
class.

For example, to find employees who work more than the average of all  
employees,
Query sub = pm.newQuery(Employee.class);
sub.setResult("avg(this.weeklyhours)");
Query q = pm.newQuery(Employee.class);
q.setFilter("this.weeklyHours > averageWeeklyhours");
q.addSubquery(sub, "double averageWeeklyhours", null);

Correlated subqueries
A correlated subquery is a subquery which contains references to  
fields in the outer query. If the correlation can be expressed as a  
restriction of the candidate collection of the subquery, no  
parameters are needed.
For example, to find employees who work more than the average of  
their department employees:
Query sub = pm.newQuery(Employee.class);
sub.setResult("avg(this.weeklyhours)");
Query q = pm.newQuery(Employee.class);
q.setFilter("this.weeklyhours> averageWeeklyhours");
q.addSubquery(sub, "double averageWeeklyhours",  
"this.department.employees");

If the correlation cannot be expressed as a restriction of the  
candidate collection, the correlation is expressed as one or more  
parameters in the subquery which are bound to expressions of the  
outer query.
void addSubquery(String variableDeclaration,
        Query subquery, String candidateCollectionExpr, String parameter);
void addSubquery(String variableDeclaration,
        Query subquery, String candidateCollectionExpr, String[] parameters);
void addSubquery(String variableDeclaration,
        Query subquery, String candidateCollectionExpr, Map parameters);
The parameters in the above methods binds parameters in the subquery  
to expressions in the outer query. String parameters are trimmed of  
white space. The single String version of the method binds the named  
expression to the single parameter in the subquery. The String[]  
version of the method binds the named expressions in turn to  
parameters in the order in which they are declared in the subquery,  
or in the order they are found in the filter if not explicitly  
declared in the subquery. The Map version of the method treats the  
key of each map entry as the name of the parameter in the subquery,  
with or without the leading “:”, and the value as the name of the  
expression in the outer query. If the trimmed expression is the empty  
String for either the parameter or the value of the String[], or for  
any map key or value, that expression is ignored.
For example, to find employees who work more than the average of the  
employees in their department having the same manager:
Query sub = pm.newQuery(Employee.class);
sub.setResult("avg(this.weeklyhours)");
sub.setFilter("this.manager == :manager");
Query q = pm.newQuery(Employee.class);
q.setFilter("this.weeklyHours > averageWeeklyhours");
q.addSubquery(sub, "double averageWeeklyhours",  
"this.department.employees", "this.manager");
The parameter in the subquery “:manager” is bound to the expression  
“this.manager” in the context of the outer query.

>
>> 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.: [phone]
>>> Buelowstr. 66                Fax.: [phone]
>>> 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!
>>
>
>
> --
> Tech@Spree Engineering GmbH  Tel.: [phone]
> Buelowstr. 66                Fax.: [phone]
> 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!