Indeed, the ‘count’ mecanism is not reliable for an arbitrary query.
According to my experience, the document count is always accurate when the post-processor is not involved.
However, when the post processor is involved, the resulting document count is over-optimistic and is equal to “number of candidate documents as according to index resolution, less the number of document eliminated by post-processing AT THE POINT where you are in the cursor set”.
So you could get an announce of “100 results” when asking for 1-10, then “92 results” when asking for 11-20, etc… Count will be correct if you ask “100-100”.
There is no systematic solution announced in the current version because having correct count would imply post-processing of the whole base.
So the work-around are:
- try to have purely index-based queries (it might not be always possible, for example if you are asking not(xxx~=…))
- ask for the “last part of the result set” so that you force post-processing of the whole result set
- change your screen design to show “Next” but not “Last” and ask everytime ‘one document more’ to make sure there is a next one
- wait for “real cursor implementation” that sould come in the coming Tamino releases: but in that case I guess there will be no more count announcement
Philippe :rolleyes:
—
Software AG Belgium, Professional Services Division
#webMethods#Tamino#API-Management