| Wes Biggs 2006-09-25, 1:11 pm |
| Hi Michael, thanks for reviewing.
I agree, it is too much to overload the existing methods. I like your
suggestion -- the only modification I would add is that the Query
parameter come first as I think that would be slightly more
readable/self-documenting.
e.g. addSubquery(Query sub, String variableDeclaration, String
candidateCollectionExpression)
Some minor points:
addSubquery() in all its forms should throw an exception if ...
-- sub.getPersistenceManager() != this.getPersistenceManager()
-- sub has been closed
-- "this" has been closed (duh)
-- "this" has been made unmodifiable
-- the derived type of the candidateCollectionExpression does not match
the declared extent type of sub
-- the variableDeclaration type does not match the declared return type
of sub
It would make things simpler if the IgnoreCache setting had to be the
same for both as well. Or we might say the IgnoreCache value for the
outer query overrides any subqueries.
Also, while the candidates for the subquery will be overridden at the
time when execute() is invoked on the outer query, it would be nice if
that was non-mutating, though we should take some advice from
implementers on what the following use case should do:
Query avgSalary = pm.newQuery(Employee.class);
avgSalary.setResult("avg(this.salary)");
avgSalary.setCandidates(someEmployees); // for argument's sake
// Invoke directly -- against someEmployees collection
Float result1 = (Float) avgSalary.execute();
Query aboveDeptAvg = pm.newQuery(Employee.class, "this.salary > avgSalary");
aboveDeptAvg.addSubquery(avgSalary, "float avgSalary",
"this.department.employees");
// Invoke as subquery -- someEmployees collection is ignored
Collection employees = (Collection) aboveDeptAvg.execute();
// Now invoke the subquery directly again -- does this use someEmployees?
Float result2 = (Float) avgSalary.execute();
I would prefer that result1.equals(result2) -- this implies that the
implementation must internally revert the candidate extent or collection
for avgSalary after it is used as a subquery; for the spec it just means
that using a Query as a subquery does not modify any of its own
candidate settings.
Wes
Michael Bouschen wrote:
[vbcol=seagreen]
> Hi Wes,
>
> thanks for the feedback, it's definitely not too late.
>
> I like your proposal. It allows subqueries being supported in both the
> SSJDOQL and the query API. I like the the idea of explicitly setting
> subquery's candidate collection by passing an expression of the outer
> query (and use the same mechanism for the parameters of the subquery).
> This solves the biggest problem I had with using a separate Query
> instance for the subquery: now the subquery instance is self-contained
> and compiles, because it does not explicitly use an expression from
> the outer query.
>
> I'm just wondering whether we could find a more intuitive syntax,
> because name(candidateExpression[,parameterExpression...]) looks more
> like a method than a variable. Furthermore, as a corner case, it might
> be possible that a query uses more than one subquery. All the
> subqueries would have to be defined in a single call of
> outer.declareVariables. So how about, if we introduce a new method
> called addSubquery to bind a single subquery to the outer query. The
> method takes separate arguments for the candidate collection
> expression and the parameters (if any). Actually the parameter
> handling could be very similar to the parameters of the execute call:
> addSubquery(String variableDeclaration, Query subquery, String
> candidateCollectionExpr);
> addSubquery(String variableDeclaration, Query subquery, String
> candidateCollectionExpr, String parameter);
> addSubqueryWithArray(String variableDeclaration, Query subquery,
> String candidateCollectionExpr, String[] parameters);
> addSubqueryWithMap(String variableDeclaration, Query subquery, String
> candidateCollectionExpr, Map parameters);
>
> Looking at the first example from below, the definition of the
> subquery would be the same. The only line that changes is the
> declareVariable call. It is replaced by:
> q.addSubquery(""float averageSalary", sub, "this.department.employees");
>
> Just for completeness we should add a method to clear the subqueries,
> such that you can reuse the outer query and bind new subqueries for
> another execute call:
> clearSubqueries();
>
> What do you think?
>
> If we think the above is option I would come up with an updated
> summary of JDOQL changes to support subqueries and updated version of
> the sample queries.
>
> Regards Michael
>
[chop]
|