On 20/06/2008, at 7:07 PM, Øyvind Harboe wrote:
> A query returns a List. This always seemed too broad an
> interface for that return value to me.
>
> There are two things that I dare do with the list that is returned:
>
> - iterate over it
> - ask for it's size()
>
> A List promises so many things:
>
> - can I modify the list?
not sure about the query results, but for sure you can modify a list
which is a result of RelationshipQuery
>
> - can I check if the list contains an object?
well... do you really want to with paged list ? (see further down)
>
> - are there any rules w.r.t. thread access/synchronisation?
> - can I compare the list to another list(all objects in Java
> implement equals)?
>
>
> Consider contains() for IncrementalFaultList(paged query). It *could*
> return false even if the query returned the object. Or rather, if I
> add
> weak references to IncrementalFaultList and do not modify it it
> could.
>
> /**
> *..ee java.util.Collection#contains(Object)
> */
> public boolean contains(Object o) {
> synchronized (elements) {
> return elements.contains(o);
> }
> }
>
> The applications I work on use only the Iterable interface,
> even if performQuery() returns a List and then only from
> a single thread.
From my experience using contains() on IncrementalFaultList faults
all the records, and therefore invalidates the idea of using paging.
initially Incremental fault list contains page size of faulted objects
and objectIds for the rest. when you do get(x) where x is outside the
page then a new page is faulted.
With regards
Marcin
This archive was generated by hypermail 2.0.0 : Fri Jun 20 2008 - 06:16:45 EDT