Re: Subquery specification update

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

Regards Michael

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.

Subqueries
void addSubquery (Query subquery, String variableDeclaration,
        String candidateCollectionExpression);



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

Query sub = pm.newQuery(Employee.class);
sub.setResult("avg(this.weeklyhours)");
Query q = pm.newQuery(Employee.class);
q.setFilter("this.weeklyhours> averageWeeklyhours");



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);

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");

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

Craig

On Oct 25, 2007, at 8:37 AM, Michael Bouschen wrote:

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?

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 >


Christiaan,


Regards Michael

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 AVG(e.weeklyhours) FROM Employee e WHERE e.manager == this.manager) yes, I think the query code you added to your email returns the same result.

-matthew

On Oct 25, 2007, at 5:07 AM, Christiaan wrote:

Hi Craig,

for candidateCollectionExpression

evaluated. "

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

the examples are very informative. I must say that I find the description "The candidateCollectionExpression is the expression using tokens from this query that represent the candidates over which the subquery is 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 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.

--
[EMAIL PROTECTED] Engineering GmbH  Tel.: +49/(0)30/235 520-33
Buelowstr. 66                Fax.: +49/(0)30/217 520-12

10783 Berlin mailto:[EMAIL PROTECTED] 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:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

--
[EMAIL PROTECTED] Engineering GmbH  Tel.: +49/(0)30/235 520-33
Buelowstr. 66                Fax.: +49/(0)30/217 520-12

10783 Berlin mailto:[EMAIL PROTECTED] 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:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature