If this helps, here is the output of xdmp:query-trace():
2009-09-23 14:47:45.658 Info: Docs:
/MarkLogic/appservices/utils/higher-order.xqy line 2: Analyzing path
for search: collection()/article
2009-09-23 14:47:45.658 Info: Docs:
/MarkLogic/appservices/utils/higher-order.xqy line 2: Step 1 is
searchable: collection()
2009-09-23 14:47:45.658 Info: Docs:
/MarkLogic/appservices/utils/higher-order.xqy line 2: Step 2 is
searchable: article
2009-09-23 14:47:45.658 Info: Docs:
/MarkLogic/appservices/utils/higher-order.xqy line 2: Path is fully
searchable.
2009-09-23 14:47:45.659 Info: Docs:
/MarkLogic/appservices/utils/higher-order.xqy line 2: Gathering
constraints.
2009-09-23 14:47:45.659 Info: Docs:
/MarkLogic/appservices/utils/higher-order.xqy line 2: Step 2 test
contributed 1 constraint: article
2009-09-23 14:47:45.659 Info: Docs:
/MarkLogic/appservices/utils/higher-order.xqy line 2: Search query
contributed 1 constraint: cts:word-query("hello", ("lang=en"), 1)
2009-09-23 14:47:45.671 Info: Docs:
/MarkLogic/appservices/utils/higher-order.xqy line 2: Executing
search.
2009-09-23 14:47:45.701 Info: Docs:
/MarkLogic/appservices/utils/higher-order.xqy line 2: Selected 99
fragments.
also, the trace says it selected 99 fragments, which is the correct
number of results, but the @total attribute reported 72 results from
search:search("hello",$options,51,10)
On Wed, Sep 23, 2009 at 2:29 PM, Bruce Holt <[email protected]> wrote:
> I do have an index on the rank attribute. search:check-options
> returns an empty sequence. I have <debug> turned on so I can see the
> search:report element, which only returns one for the FLWOR
> expression. I don't have any fragment roots specified as the
> <article> is the root element I want returned and counted. Any other
> ideas?
>
> Thanks,
>
> Bruce Holt
>
> On Wed, Sep 23, 2009 at 1:46 PM, Colleen Whitney
> <[email protected]> wrote:
>> Do you have an index on the rank attribute? If not, that would explain the
>> problem. Without the index, the order-by will cause filtering to happen,
>> which is likely to make cts:remainder incorrect.
>>
>> Running search:check-options($options,true()) during development can help
>> you catch issues like this; the second argument is a flag that runs a check
>> to see if the indexes you need (based on your options) are in place.
>>
>> --Colleen
>> ________________________________________
>> From: [email protected]
>> [[email protected]] On Behalf Of Bruce Holt
>> [[email protected]]
>> Sent: Wednesday, September 23, 2009 12:19 PM
>> To: General Mark Logic Developer Discussion
>> Subject: Re: [MarkLogic Dev General] search:search @total changes when
>> sorting.
>>
>> Thanks for the reply.
>>
>> Any idea why I consistently get the correct result when it sorts by
>> score (the default sort) as compared to sporadic results when I sort
>> by the rank attribute as described below? All I am changing is the
>> sort order, why would that affect the total?
>>
>> On Wed, Sep 23, 2009 at 1:14 PM, Micah Dubinko
>> <[email protected]> wrote:
>>> Hi Bruce,
>>>
>>> For raw speed, the Search API uses cts:remainder() to quickly get an
>>> estimated number for the total. Are you using fragment roots by
>>> chance? That can cause the specific number to vary, much like with
>>> search engine results.
>>>
>>> The specific calculation is cts:remainder( of first result ) + $start
>>> - 1.
>>>
>>> If the underlying call returns different values, so will what you see
>>> in the Search API results.
>>>
>>> Thanks, -m
>>>
>>> On Sep 23, 2009, at 11:05 AM, Bruce Holt wrote:
>>>
>>>> Hello All.
>>>>
>>>> I am using the search:search api and everything works as expected
>>>> until I sort by an element or attribute in my document. Once I sort
>>>> by an element or attribute, the @total for <search:response> changes
>>>> as I paginate through the results. I have several <article> documents
>>>> that I am searching through with an Integer Attribute Range Index on
>>>> "authorRole/@rank". When I add <sort-order type="xs:integer"
>>>> direction="ascending">
>>>> <element ns="" name="authorRole"/>
>>>> <attribute ns="" name="rank"/>
>>>> </sort-order>
>>>> to my search options, the @total is no longer accurate. For a search
>>>> with 99 hits, paging through the results changes @total from 21 to 147
>>>> results. Any Ideas? An example <article> document is below.
>>>>
>>>> <article status="publish">
>>>> <referenceHeader>
>>>> <publicationDate
>>>> value="2008-11-01T00:00:00">2008-11-01</publicationDate>
>>>> <searchTerms>
>>>> <authorRole rank="6" seniority="1">Role ABC</authorRole>
>>>> <collection>misc</collection>
>>>> </searchTerms>
>>>> <lastChanged>
>>>> <editor>John Smith</editor>
>>>> <dateStamp>2008-10-23</dateStamp>
>>>> </lastChanged>
>>>> <itemNumber>62291</itemNumber>
>>>> </referenceHeader>
>>>> <titleBlock>
>>>> <title id="1">The Title</title>
>>>> <kicker id="4">This is very interesting.</kicker>
>>>> </titleBlock>
>>>> <bodyBlock>
>>>> <para id="5" start="00:00:00:00" stop=""><pageBreak
>>>> pageNum="75"/>This is paragraph 1 and
>>>> that is all I have to say here.</para>
>>>> <para id="6" start="00:00:00:00" stop="">Yes! Another
>>>> paragraph.</para>
>>>> </bodyBlock>
>>>> <publishDate value="2009-07-22T09:52:48.887-06:00">2009-07-22</
>>>> publishDate>
>>>> </article>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Bruce Holt
>>>> _______________________________________________
>>>> General mailing list
>>>> [email protected]
>>>> http://xqzone.com/mailman/listinfo/general
>>>
>>> _______________________________________________
>>> General mailing list
>>> [email protected]
>>> http://xqzone.com/mailman/listinfo/general
>>>
>> _______________________________________________
>> General mailing list
>> [email protected]
>> http://xqzone.com/mailman/listinfo/general
>> _______________________________________________
>> General mailing list
>> [email protected]
>> http://xqzone.com/mailman/listinfo/general
>>
>
_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general
