鉴于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"):)