I wonder if custom constraints might work better for you? There's a  
nice example in the search developer's guide.

On Jun 1, 2010, at 2:05 AM, "Pradeep Maddireddy"  
<[email protected]> wrote:

> Hi Colleen,
>
> I have a requirement where I have to fetch documents which satisfy
> one of  the following conditions
> Q1.  price = 100
> Q2.  publish-date Before(less than)  2009-01-01
>
> and Q3.  Belong to Collection "Books"
>
> basically  (Q1 OR Q2) AND Q3
>
> I am building the search term price:100 and passing it as search term.
> As the search API doesn't support greater than and less than I am
> building cts:element-range-query and collections-query and passing it
> in additional_query part of options Node
>
> but this becomes  Q1  AND  (Q2 AND Q3).
>
> It could have been helpful, if we had an or-part and and-part in
> additional query.
>
> As I couldn't think of any work around, I built one more
> element-range-query for Q1 as well and passed it as additional
> Query.So every thing will be in additional Query and no search term.
>
> My search can have even more complex conditions than the one  
> mentioned above.
>
> Also thought of   bucket range constraints, but it expects a range
> and accepts only >=
> (greater than or Equal to) and < (less than) . It is possible to build
> a range  bucket by specifying only  >=,
> say year >= 2000, but it is not possible to create a constraint as
> year < 2000, the search API fails in this case.
>
>
> Thanks
> Pradeep
>
> On 6/1/10, Colleen Whitney <[email protected]> wrote:
>> Pradeep,
>>
>> Additional-query terms are not included in snippet highlighting,  
>> because
>> terms in additional-query are not supplied by the end user. It's  
>> easy to
>> imagine use cases in which the additional-query represents  
>> "bookkeeping"
>> terms that the end user doesn't care about (but the developer  
>> does); at the
>> time of the decision, it seemed like the use cases where such terms  
>> *should*
>> be highlighted are less common.
>>
>> Without understanding more about your constraints, it's hard to  
>> know exactly
>> what to recommend, but I don't recommend modifying the library  
>> directly.
>> That is likely to cause you pain on upgrade.  There are several
>> possibilities I can think of for you to experiment with, though.
>>
>> First, search:search() accepts a sequence of query terms in the first
>> argument; these are "anded" together in parsing, the same way that
>> additional-query terms are "anded" with the parsed query for  
>> execution. So
>> you could do search:search(("parsed","additional","another"), 
>> $options),
>> where "parsed" represents user-supplied terms, and the others  
>> represent
>> terms you are currently handling with additional-query.  All words  
>> would be
>> included in the parsed query and in highlighting.
>>
>> Alternatively, you could parse first using search:parse(), modify  
>> the parse
>> tree to add the query terms, then call search:resolve(), passing in  
>> your
>> manipulated query.  That has some risks in terms of how the parsed  
>> query
>> interacts with other features like snippeting and unparsing, but it  
>> is worth
>> exploring and testing.
>>
>> There may be other ways as well, but hopefully this is enough to  
>> get you
>> started.
>>
>> --Colleen
>>
>>
>>
>> -----Original Message-----
>> From: [email protected]
>> [mailto:[email protected]] On Behalf Of Pradeep
>> Maddireddy
>> Sent: Monday, May 31, 2010 6:59 AM
>> To: General
>> Subject: [MarkLogic Dev General] Search API Snippet Additional Query
>>
>> Hi..!
>>
>> Because of some constraints I had to use Additional Query part
>> instead of search term while using the search API. After I started
>> using the  Additional Query part, the snippet part isn't working
>> correctly, it is just returning some text instead of hit-higlighting
>> the search term.
>>
>> I check the API code, only parsed query instead of combined query
>> (parsed qry + additional qry)
>> is being passed to the do-snippet function, once I changed it to
>> combined query I got the desired output but I am just skeptical if
>> this would break any thing else.
>>
>> snip:do-snippet($result, $parsed-query,$options/opt:transform- 
>> results)
>>
>> Can someone help me.
>>
>> Thanks
>> Pradeep Maddireddy
>> _______________________________________________
>> General mailing list
>> [email protected]
>> http://developer.marklogic.com/mailman/listinfo/general
>> _______________________________________________
>> General mailing list
>> [email protected]
>> http://developer.marklogic.com/mailman/listinfo/general
>>
_______________________________________________
General mailing list
[email protected]
http://developer.marklogic.com/mailman/listinfo/general

Reply via email to