Current paginated queries do the full query, however they significantly
speed up the result processing. I.e. the optimization comes from the fact
that much less data had to be processed and cached in the app.
Yes, using a "count(1)" for paginated queries would've been faster...
Unfortunatly this would also yield unpredictable results as the database
data can change between the page faulting events.
Current approach of storing ids in the list is not 100% bulletproof, but
it ensures much more sane behavior.
Also custom faulting logic can be implemented without changing anything in
Cayenne itself. Cayenne provides a least common denominator approach,
however if your application data access/modification patterns allow for
extra optimizations you can write your own list. E.g.:
class MyPaginatedList implements List {
MyPaginatedList(DataContext context, SelectQuery baseQuery) {
}
... // implement your own faulting....
}
Andrus
> This brings up an interesting point that I've been meaning to ask about.
>
>
> When using a paging factor on a result set, I think I remember it doing
> a full query (including all fields) just to find out how many total rows
> could be returned before it queries for a subset of those rows. And it
> does this for each page I request.
>
> Is there a more efficient way, or has this way been demonstrated to be
> almost as fast as doing a count(*)?
>
> - Jonathan
>
>
>>>> andru..bjectstyle.org 2005-06-14 4:13:09 PM >>>
> Oh yeah, and as Mike pointed out you should call
>
> query.setFetchingDataRows(true);
>
> To tell Cayenne that the fetch result shouldn't be converted to
> DataObjects.
>
> Andrus
>
>> No, SQLTemplate is actually used to run arbitrary SQL. In some cases
> the
>> result can be mapped to an entity, but in most it will be just that -
> a
>> list of Map objects with each Map corresponding to a result set data.
> So a
>> count query would look like this:
>>
>> String sql = "SELECT COUNT(*) FROM SOME_TABLE"
>> DataMap queryRoot =
>> context.getEntityResolver().getDataMap("data_map_name");
>> SQLTemplate query = new SQLTemaplate(queryRoot, sql, true);
>> Map singleRow = (Map) context.performQuery(query).get(0);
>> Number count = (Number) singleRow.values().next();
>>
>> As this is a bit too verbose, 1.2 will likely encapsulate this code
> in a
>> generic utility class. For now you can create your own.
>>
>> Andrus
>>
>>
>>
>>> I read through that documentation, but it doesn't really appear to
> do
>>> anything different then the normal SelectQuery besdies being able
> to
>>> write it in SQL. I was wanting to do something like SELECT COUNT(*)
>>> FROM Object and just got the int result, with out loading all the
>>> child records etc.
>>>
>>> Just reading the docs there it doesn't appear to let me do
> something
>>> like
>>> that.
>>>
>>> -Nick
>>>
>>> On 6/14/05, Mike Kienenberger <mkienen..laska.net> wrote:
>>>> Nick Stuart <nicholas.stuar..mail.com> wrote:
>>>> > This should be an easy one. I basically just want to find out
> how
>>>> many
>>>> > objects of a certain type there are. Easy to do with a
> SelectQuery
>>>> and
>>>> > user List.size() but does the cause any kind of performance
> issues?
>>>> > Just thinking if these objects have child objects, which has
> more
>>>> > child objects, will it pull all those when I Select the parent?
>>>>
>>>> If you only want the count and don't want to load any objects, just
> use
>>>> SQLTemplate.
>>>>
>>>> http://www.objectstyle.org/cayenne/userguide/fetch/sqltemplate.html
>
>>>>
>>>
>>
>>
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>
> ______________________________________________________________________
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager.
>
> Katun Corporation -- www.katun.com
> _____________________________________________________________________
>
This archive was generated by hypermail 2.0.0 : Wed Jun 15 2005 - 15:05:28 EDT