| Michael Bouschen 2006-09-26, 7:11 pm |
| Hi Wes,
I agree with what you are proposing below. Some more comments inline ...
> 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)
Sounds good.
>
> 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
I agree. Just a minor change: the element type of the
candidateCollectionExpression must be compatible with the candidate
class of the subquery.
>
> 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.
Yes, the IgnoreCache value of the outer query should win.
>
> 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.
Yes, I would prefer this, too. So let's see whether there are any issues
with this from the implementation point of view.
Thanks again for the feedback.
Regards Michael
>
> Wes
>
>
> Michael Bouschen wrote:
>
> [chop]
--
Michael Bouschen Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
|