A complaint about something being unsearchable will only result from
a call to cts:search or a related function. Can you please show the actual
search call you're making? The partial FLWOR you include below should
be fine and is not the source of the unsearchable messages.
In general you search elements or attributes. With elements you're
actually searching hierarchies of elements (trees). The specific query
constructor you use determines how values of elements are interpreted,
either as values or as broken into words. You specify paths of elements
to search, not their text nodes.
As you mention, text() is not the same thing as a string. The result
of a text() XPath step is a node, not an atomic string. If you want to
extract a string value from an element, you should generally use a call
to the fn:string function as the last step.
While "text()" looks like a function call that will return the text value of
an element, that's not what it is. It is a type matcher that matches nodes
of kind text. In most situations, a node of kind text will atomize as a string,
so this causes many programmers to write code that assumes this. But
this is really a source of latent bugs. If you mean string value, use
fn:string().
---
Ron Hitchens {[email protected]} +44 7879 358212
On Sep 10, 2013, at 12:30 PM, Rachel Wilson <[email protected]> wrote:
> Hi ML team,
>
> We have been using xdml:query-trace to analyse a slow running query and have
> eliminated all of our "unsearchable"s except one, which we don't fully
> understand.
>
> In the ErrorLog output we see "Step 4 is unsearchable: text()" for any
> property we retrieve with "text()" as follows:
>
> Eg.
>
> for $documentUri in $uris
> let $documentProperties := xdmp:document-properties($documentUri)
> let $modifiedBy :=
> $documentProperties/prop:properties/prop:modifiedBy/text()
>
> I think we're just realising that we shouldn't be getting the text node with
> text() anyway but use string() but in any case I'm curious to know why that
> text node is unsearchable. Just for my understanding.
>
> When using text() like this does ML go back to disk as suggested in the
> "Tuning Queries with query-meters and query-trace (Query Performance and
> Tuning Guide)" which says "Expressions that are unsearchable cannot use the
> indexes, and must fetch the data from disks"? I am new to marklogic and in a
> little at the deep end with this analysis so excuse any false assumption, but
> I would have assumed that the documentProperties are now in memory and so
> calling text() on that in memory object should read from memory (if not the
> index) and not go back to disk. Is that true? But in any case why is it
> considered unsearchable at all?
>
> Would be grateful for an explanation and to set me straight on any
> misunderstandings.
>
> Many thanks,
>
> Rachel
>
> PS. And actually we've just determined that string() is unsearchable as well
>
>
> ----------------------------
>
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and may contain personal
> views which are not the views of the BBC unless specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in reliance
> on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
> ---------------------
> _______________________________________________
> General mailing list
> [email protected]
> http://developer.marklogic.com/mailman/listinfo/general
_______________________________________________
General mailing list
[email protected]
http://developer.marklogic.com/mailman/listinfo/general
