Re: List methods returned from a paged query

[Marcin Skladaniec]

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?



Consider contains() for IncrementalFaultList(paged query). It *could*

weak references to IncrementalFaultList and do not modify it it
could.

   /**
    * @see 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.

- can I compare the list to another list(all objects in Java implement equals)? return false even if the query returned the object. Or rather, if I add

With regards
Marcin

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.

smime.p7s
Description: S/MIME cryptographic signature