total number of matched results

[KevinBenson]

Yes it is useful information.  And as I think about it more much like 
relational db's, I should be able to do a count()  in the XMLDB.  
Granted memory consumption wise it might be best to do a small 2nd query 
for an XMLDB instead of loading all the Resource documents at one time 
in the first query to just produce the count.  I thought relational db's 
would take advantage of the Limit clause which I suspect means a 2nd 
type query for count(*) would need to take place, but I could be wrong 
(but it seems a 2nd query would be needed in mysql when I just tried it).

How about we leave it out for now?  Till implementations (both client & 
server) have a little more time to experiment on the "paging".  Once we 
experiment more we can add it to the RI on the next version.

cheers,
Kevin

Ray Plante wrote:
> On Fri, 16 Jun 2006, Kevin Benson wrote:
>   
>> But I should note I am not in favor of it much.  If you think of 
>> Relational db's and XMLDB's I would rather write a query that gets to a 
>> limit like "100" (or actually 101 and strip off the last Resource Record). 
>> And tell the user that there is more 
>> with the more="true" attribute. Like we have now.  Instead of doing a huge 
>> query to be put in memory only to populate one attribute of somehting like
>> count="8000" and return back my limit of 100 resources.  
>>     
>
> I see what you are saying.  Suppose you want to say limit 100; how do you, 
> then, in your database ask for the 2nd 100 records (because the user said 
> <from>101</from><to>200</to>)?  Would do a limit 201 and strip off the 
> first 100?  I think that's what you'd have to in standard SQL.  In this 
> case, it seems that a client that is going to process all matching records 
> would eventually force the database to load 8000 records (and 7900, 
> 7800, ...).
>
> I'm fine with leaving it out, but it is useful information.  A user 
> knowing that there are 8000 matching results (even if 100 are 
> returned) might be inclined to refine the next query to match fewer 
> results.  
>
> cheers,
> Ray
>
>
>