Hi, >>>2. The client does need to know the size, so it calls getSize() and >> >> I currently can't come up with a convincing use case - what is your use >> case? > >Display the actual number of search results to the user?
Do you want to risk that the method getSize() takes 1.5 hours just to display the actual number of search results to the user? In this case, I suggest the application doesn't always display the exact size, he could display one of the following instead: * 0 hits * 2 hits * 13 hits * 23 hits * More than 30 hits The reason for the "More than 30 hits" versus the exact number of hits is: calculating the exact number of hits is very inefficient if there are more than just a few hits. For example, it doesn't make any sense to display "1045430 hits" if calculating this number takes 1.5 hours. >If they show "next page", they usually also show the number of results >and the number of pages. Yes, I understand it is a nice feature. But it is a very dangerous feature given the problems described above. >In many cases the paging etc. doesn't have to be exact, so if there is a >way that Oak could provide a fairly good estimate that would be really >cool (like caching the numbers). Estimating the result size is sometimes possible, that's true, but it is potentially a security problem. Do you want me to describe the attack scenario? It is easier for Google and so on where everybody may see everything. Regards, Thomas
