Marklogic search development -2.3 Search Term Completion Using search:suggest

鉴于term completion对于searchapplication的重要性，因此独立出这个功能点。 它确实也不同于search。Search是用来配合用户querystring工作的，即转换query string为相应的cts：search，设置查询scope，处理查询结果sinppet等等。而termcompletion更是一种用户体验的功能，它并不是用户search的目标，它是辅助用户设置query string的功能。

Marklogic中支持此功能的就是search:suggest.

通常的使用场景时：用户浏览器中，设置Javascript来监听用户的querystring的输入，获取输入发起异步的marklogic search：suggest call。用户type单词，获得search：suggest的结果以便提供用户体验。

2.3.1        default-suggestion-source Option

search:suggest我们知道它也是基于用户的输入，去database中查询获取相关的信息给到用户，以便提升用户体验。因此其必然在marklogicserver端存在一个这样的数据源以便用于查询。

整个数据源显然不应该是整个数据库（index），应该给的更有意义一些。 如：当你输入“三星”的时候，这个数据源可以提供诸如：三星手机/三星电视/三星电子 等等的信息。显然这些信息不是来自数据库的（你的数据库中可能有“三星上将/他是个三星级酒店”等等）。那么这个样的数据源貌似一定是需要进行人工维护的。否则给出的结果就不makesense了。（通常有使用人工维护或者机器学习等）。

知道了term completion, search:suggestion的效果及工作方式.因此marklogicdatabase必然也需要提供这样一个数据源来支持整个feature。这就是我们的default-suggestion-source.

我们知道这个source是需要维护的，一旦我们没有维护这个东东。或者用户的输入没有在source里面进行相应的维护，我们这个feature又会如何呢？这里marklogic考虑了这样的情景，在此场景下，marklogic会将searchoption中定义的constraint和operator做为这个source给到用户的。这样的处理就是水到渠成的感觉，因为我们知道constraint是来做searchscope的；operator用来提升用户体验的。它们能提供给最终用户是多么的及时和有用。

既然我们知道suggest背后有这样一个source。那么在大数据的情况下，我们就要考虑searchperformance的问题。 最佳实践：大数据下，使用rangeindex/collection来替代word lexicon。顺理成章，wordlexicon的粒度要远远低于string range index和collection。所以这个source的scope就会变小，performance自然提升。

<default-suggestion-source>

<range type="xs:string">

<element ns="my-namespace"name="my-localname"/>

<attribute ns=""name="my-attribute"/>

</range>

</default-suggestion-source>

（source来自my-localname的my-attribute）

Range index是针对element或者attribute的，而wordlexicon，天啊，是针对所有内容的！

2.3.2        Choose Suggestions With the suggestion-sourceOption

我们知道search:suggest是工作在一个suggestion-source上的，那么如果这个source拥有hugerecord那么会怎样？第一suggest term会非常多，第二performance有影响。 因此我们需要一个方案可以进一步限定source中的特定记录集用作source。 这个就是suggestion-source option了。

<constraintname="name">

<rangecollation="http://marklogic.com/collation"

type="xs:string"facet="true">

<elementns="my-namespace" name="fullname"/>

</range>

</constraint>

<suggestion-sourceref="name">

<rangecollation="http://marklogic.com/collation"

type="xs:string"facet="true">

<element ns="my-namespace"name="short-list-name"/>

</range>

</suggestion-source>

可以看到，我们定义了name这个constraint，我们知道constraint是用来在一定的word/value/collection之中进行search的。那么我们可以认为它就是一个search的结果级别。而你看到ref=“name”很明确的，表示suggestion-source将会使用name这个constraint的结果集。而其中二次定义的name=”short-list-name”将会使用新的search条件来获取search 结果集。

一个问题：这样的结果集是在constraint执行前进行filter还是等constraint结果集执行后进行filter？

2.3.3        Use Multiple Query Text Inputs to search:suggest

当用户输入多个search term的时候，是个什么情形？

Search:suggest会将第一个term会用来去再suggest-resource中做matchingsearch的操作，而之后的若干的term会解析成相应的cts：query，并使用and-query的方式将他们combine起来。

如上：你可以输入comp，但同时你checked了decade:1980s.假设这里decade:1980s是个针对constraint道德查询（cts：query）,那么以上场景你的search：suggest如下：

Search:suggest((“comp”,”decade:1980s”),$option)

这代表是用comp*在suggest-resource中进行search，同时使用constraintsearch：”decade:1980s”.来限定结果集.

2.3.4        Make Suggestions Based on Cursor Position

如题，这个可以按照鼠标位置取相应的term进行suggest的查询。

当然，这个鼠标（光标）位置需要客户通过$cursor-posistion来进行传达。

2.3.5        search:suggest Examples

Assume a constraintnamed filesize for the following example:

query:suggest("fi",$options)

(:Returns the "filesize" constraint name first, followed

bywords from the default source of word suggestions:

("filesize:", "field","file", "fitness", "five",) :)

 

The followingexample shows how search:suggest works with bucketed range constraints:

(:Assume $options contains the following:

<constraintname="date">

<rangetype="xs:dateTime">

<bucketname="today">

<bucketname="yesterday">

<bucketname="thismonth">

<bucketname="thisyear">

...

:)

search:suggest("date:",$options)

(:bucket names from the "date" range constraint are

used tocreate suggestions

("date:thismonth","date:thisyear", "date:today", "date:yesterday"):)