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 <[EMAIL PROTECTED]> 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?
