Chris Hostetter wrote:
: not hard, but useful information to have handy without additional
: manipulations on my part.
: our pages are the results of multiple queries. so, given a max number of
: records per page (or total), the rows asked of query2 is max - query1, of
in the common case, counting the number of "doc"s in a "result" is just as
easy as reading some attribute containing the count.
I suppose :) in my mind, one (potentially) requires just a read, while
the other requires some further manipulations. but I suppose most
modern languages have optimizations for things like array size :)
It sounds like you
have a more complicated case where what you really wnat is the count of
how many "doc"s there are in the entire response
I don't know how complex it is to ask for documents in the response, but
yes :)
(ie: multiple "result"
sections) ...
multiple results from multiple queries, not a single query.
but really, I wasn't planning on having anyone (solr or otherwise)
solving my needs. I just find it odd that I need to discern the number
of returned results.
that count is admitedly a little more work but would also be
completley useless to most clients if it was included in the response
perhaps :)
(just as the number of fields in each doc, or the total number of strings
in the response) ... there is a lot of metadata that *could* be included
in the response, but we don't bother when the client can compute that
metadata just as easily as the server -- among other things, it helps keep
the response size smaller.
agreed - smaller is better.
as for client as easily as a the server, I assumed that solr was keeping
track of the document count already, if only to see when the number of
documents exceeds the rows parameter. if so, all the people who care
about number of documents in the result (which, I'll assume, is more
than those who care about total strings in the response ;) are all
re-computing a known value.
This was actually one of the orriginal guiding principles of Solr: support
features that are faster/cheaper/easier/more-efficient on the central
server then they would be on the clients (sorting, docset caching,
faceting, etc...)
sure, I'll buy that. but in my mind it was only exposing something solr
already was calculating anyway.
regardless, thanks for taking the time :)
--Geoff
