db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Subquery specification update
Date Thu, 25 Oct 2007 16:38:28 GMT
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.: +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 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 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!


Mime
View raw message