| Wesley Biggs 2006-10-07, 7:11 pm |
| Craig,
This approach (adding subqueries by value) sounds good to me. Simple,
elegant and easier on the spec-writing committee. ;-)
Wes
Craig L Russell wrote:
> Hi Wes and Michael,
>
> I'm just now reviewing this. Very nice indeed.
>
> We need to consider what happens if a subquery is modified after being
> added to an outer query. I'd like to propose that we treat the
> subquery as supplying certain pieces and excluding others. We have a
> similar situation with serialization of a Query instance, that I think
> we can model for this purpose.
>
> <spec>
> The class implementing the Query interface must be serializable. The
> serialized fields in-
> clude the candidate class, the filter, parameter declarations,
> variable declarations, imports,
> ordering specification, uniqueness, result specification, grouping
> specification, and result
> class. The candidate collection, limits on size, and number of skipped
> instances are not se-
> rialized. If a serialized instance is restored, it loses its
> association with its former Persis-
> tenceManager.
> </spec>
>
> I'd suggest that we adapt this for subqueries as follows:
>
> The query parameter 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 in-
> clude 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 implications are:
>
> changes made to the subquery after addSubquery are not reflected in
> the outer query
>
> the subquery can be executed without affecting the outer query
>
> the same subquery can be used multiple times in the same or other
> outer queries
>
> the candidate instances of the subquery itself are not considered;
> either the candidates are identified in the addSubquery method or the
> extent of the candidate class is used
>
> serialized/restored queries can be used as parameters for addSubquery
>
> there is no limitation on the use of a query that is bound to a
> different PersistenceManager
>
> the range feature is not usable (this is probably a good thing for
> subqueries)
>
> A few more comments below.
>
> On Sep 26, 2006, at 1:30 PM, Michael Bouschen wrote:
>
>
> no; see above
>
>
> queries are not closed; results are closed
>
>
> queries are not closed; results are closed
>
>
> Yes. When avgSalary was used as a subquery, the relevant parts of the
> query, not including the candidates, were used and avgSalary itself
> was not modified.
>
>
> I think it's easier for everyone to consider addSubquery to simply
> copy the parts of the query of interest and leave the query intact.
>
> Craig
>
> 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!
>
|