Not sure if it helps, but you could split up the parse and resolve phases: search:resolve( cts:or-query((search:parse($user-query), $custom-query)), $options)
This technique avoids the additional-query entirely. Highlighting will use the full query, but that generally shouldn't be a problem. -- Mike On 15 Mar 2012, at 01:14 , Steve Adcock wrote: > Alright, think I'm making progress here. I'm using the additional-query tag > and I'm simply using a regular cts:or-query within that node. I wouldn't > consider this an elegant solution, though... > > -- > Steve Adcock - Software Developer > 42Six Solutions | Tucson, AZ > (o) 520.269.7500 > (c) 520.975.3867 > http://www.42six.com > > > > On Wed, Mar 14, 2012 at 6:08 PM, Steve Adcock <[email protected]> wrote: > Thank you Will and Mike for your responses. We are building our constraints > a little differently...we aren't using the typical syntax that Will cited, so > it's making things a little more difficult. I guess what I'm looking for is > the additional-query tag, but using OR logic instead of AND. I am testing > successfully using AND, but I need OR. > > -- > Steve Adcock - Software Developer > 42Six Solutions | Tucson, AZ > (o) 520.269.7500 > (c) 520.975.3867 > http://www.42six.com > > > > On Wed, Mar 14, 2012 at 4:49 PM, Michael Blakeley <[email protected]> wrote: > It might help to separate the idea of security from the idea of entitlements. > A security model is good for hiding content that a given role should never > see. An entitlements model is good for optional hiding of content that a user > may or may not be able to see in various contexts. > > The best way to implement an entitlements model is with additional-query. For > example, you might have an XXX collection that the user is entitled to see. > If the user selects "limit to available documents" then you silently add an > additional query on collection XXX. If the user wants to see all results, you > leave that out. > > -- Mike > > On 14 Mar 2012, at 21:56 , Steve Adcock wrote: > > > Guys, > > > > Trying to figure out the best way to extend a portion of an application > > that I'm working on that uses the search:search feature of MarkLogic. > > Here's the deal...in MarkLogic, we are storing a bunch of documents, and > > each document contains something of a DocType node. We also have a bunch > > of constraint tags that restrict the data coming back, and one of those > > constraints does a restriction based on the user that inserted the > > document. So by default, users only see the documents that they inserted. > > > > However, I want to extend this functionality so it maintains its user > > restriction, but for a DocType of "XXX", I want to return that as well. So > > basically, return all user documents, AND all XXX DocType documents. > > > > Is there a decent way to add this functionality using constraints? I'd > > rather not issue another query if at all possible. What's the most > > efficient way to do this? > > > > Thanks. > > > > -- > > Steve Adcock - Software Developer > > 42Six Solutions | Tucson, AZ > > (o) 520.269.7500 > > (c) 520.975.3867 > > http://www.42six.com > > > > _______________________________________________ > > 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 _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
