I had never used the paginated queries, but I would've bet money that it
fetched only the PKs initially and then fully resolved objects on a per-page
basis as needed. On large datasets, it is a big win (in time and memory) to
do it that way. On smaller datasets, it would be about a wash either way --
not significant. Seems to me that would be the logical default setting and
maybe an option to do it the other way if the developer knows his dataset
would fetch faster that way.
/dev/mrg
On 5/25/07, Andrus Adamchik <andru..bjectstyle.org> wrote:
>
>
> The default strategy, as implemented by
> org.apache.cayenne.access.IncrementalFaultList, is to run a full
> query to fully resolve page #1, but only read id columns from the
> result set for pages 2, 3, etc... This strategy bets that a single
> fat SQL query with full ResultSet fetching, but without reading
> unneeded columns is faster than a PK-only query followed by a second
> query to resolve page #1.
>
> In some circumstances this is true, in some (like yours) it is
> clearly not. I am leaning towards making a second strategy the
> default, as paginated queries are really intended for the huge result
> sets... Anybody has other thoughts on that?
>
This archive was generated by hypermail 2.0.0 : Fri May 25 2007 - 09:03:22 EDT