cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcin Skladaniec <mar...@ish.com.au>
Subject Re: List methods returned from a paged query
Date Fri, 20 Jun 2008 09:35:36 GMT

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

 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


Mime
View raw message