search for: op_or

...terms in addition to numeric values when indexing, but currently I have a set of numeric values[1] and trying to avoid having to reindex ~250GB DBs (and asking numerous users to do the same). Say I have a bunch of values which I want to filter a query against. If I had boolean terms, it could just OP_OR against the whole set. IOW, this is what notmuch does with terms: std::set<std::string> terms; // notmuch populates terms via terms.insert(*i)... Query(OP_OR, terms.begin(), terms.end()); // Disclaimer: I don't really know C++ With a set of integers I have (after sortable_seriali...

On Fri, Apr 26, 2024 at 10:37:37PM +0000, Eric Wong wrote: > Say I have a bunch of values which I want to filter a query against. > If I had boolean terms, it could just OP_OR against the whole set. > IOW, this is what notmuch does with terms: > > std::set<std::string> terms; > > // notmuch populates terms via terms.insert(*i)... > > Query(OP_OR, terms.begin(), terms.end()); The slicker way to do this (unless you need the std::set for ot...

Hi, I've been using Xapian for a while. But there is a scene I don't know whether supported already. Suppose: 1. Raw query: how to make pizza 2. Parsed query: how AND to AND make AND pizza 3. Documents: d1: how to make pizza at home d2: 3 ways to make pizza d3: make pizza in 4 easy steps Question: 1. During searching process, how to retrieve d2, d3 (although they don't

...ay, > > proximity of phrases does make sense in this case, if there is a > > wishlist somewhere, but it's admittedly not an issue that most users > > will be concerned with...). > > Another case for https://trac.xapian.org/ticket/508 I think. The ticket only lists OP_OR as subqueries, but this case would be a bit different, because one of the OR subqueries would actually be a phrase: filesystem NEAR otherterm may be transformed by synonym expansion into: (filesystem OR (file PHRASE system)) NEAR otherterm > > > * Currently the OP_OR subqueries can...

...rases does make sense in this case, if there is a > > > wishlist somewhere, but it's admittedly not an issue that most users > > > will be concerned with...). > > > > Another case for https://trac.xapian.org/ticket/508 I think. > > The ticket only lists OP_OR as subqueries OP_OR is the example used in the description, but the ticket isn't only about OP_OR - note "OP_OR, *etc*" in the description, the title says "non-leaf subqueries", and other operators are explicitly discussed: * OP_AND: https://trac.xapian.org/ticket/508#comm...

...poke at the patch and have a reworked version which solves the > object lifetime issue and works for some simple tests. Can you try it out > and see if it works for you? > > https://trac.xapian.org/ticket/508#comment:13 > > There are two limitations: > > * Only OP_OR subqueries are handled. I think supporting these would be a > useful step forward by itself, and AIUI it's all you actually need. Yes, my need arises from stem or synonym expansions occurring inside a NEAR query. This happens without the user doing anything special, so it's a prob...

The following piece of code triggers an 'unimplemented' exception with the message: "Can't use NEAR/PHRASE with a subexpression containing NEAR or PHRASE" Xapian::Query or1(Xapian::Query::OP_OR, Xapian::Query("one"), Xapian::Query("two")); Xapian::Query or2(Xapian::Query::OP_OR, Xapian::Query("three"), Xapian::Query("four")); Xapian::Query near(Xapian::Query::OP_NEAR, or1, or2); I can't decide by looking...

...se a record containing the following data : "Aut1=john lennon, Aut2=will smith" will appear in the Mset. So my questions: is the current QueryParser's behaviour the intended one? Is there anything I can do to get the result I expect? Of course, the parsing is fine when default_op is OP_OR (as it is by default), but results are also "strange for me" if I try with OP_PHRASE: Xapian::Query(((AUT1:john:(pos=1) PHRASE 2 AUT1:smith:(pos=2)) OR (AUT2:john:(pos=1) PHRASE 2 AUT1:smith:(pos=2)) OR (AUT2:john:(pos=1) PHRASE 2 AUT2:smith:(pos=2)) OR (AUT1:john:(pos=1) PHRASE 2 AUT2:s...

Olly Betts writes: > On Thu, Dec 29, 2016 at 07:21:41PM +0100, Jean-Francois Dockes wrote: > > Xapian 1.2 supports a query like: > > > > (A OR B) NEAR (C OR D) > > > > and distributes the factors to create something like: > > > > (A NEAR 2 C) OR (B NEAR 2 C) OR (B NEAR 2 C) OR (A NEAR 2 C) > > > > Xapian 1.4 rejects such

Hi All, I would like to take a doc in the xapian DB and find all related documents by relevance e.g. so when you view one document it says "Related entries X Y Z". I'm aware of the "Morelikethis" Lucene plugin that is supposed to do something like this, by generating a query from a document based on term frequency. Has anyone developed a tool to generate a query from a

...--------------------------------------------------------# my @primary_terms = split ' ', $primary_terms; my @secondary_terms = split ' ', $secondary_terms; #------------------------------------------------------------------------------# my $query1 = Search::Xapian::Query->new( OP_OR, @primary_terms ); my $query2 = Search::Xapian::Query->new( OP_OR, @secondary_terms ); my $boolean_query = Search::Xapian::Query->new( OP_AND, $query1, $query2 ); $enq->set_query( $boolean_query ); #------------------------------------------------------------------------------# printf &...

...&tname_, Xapian::termcount<http://xapian.org/docs/apidoc/html/namespaceXapian.html#72b5a76dd8cfb7b251fe7986e86390cb>wqf_=1, Xapian::termpos<http://xapian.org/docs/apidoc/html/namespaceXapian.html#e5a16f073d0c8ed54085a9de07248d45>pos_=0) : Xapian::Query query_test(Xapian::Query::OP_OR, Xapian::Query("Bonjour", 10), Xapian::Query("Hello", 5)); Xapian::TermIterator qt = query_test.get_terms_begin(); while (qt != query_test.get_terms_end()) { cout<<*qt<<" "<<qt.get_wdf()<<" "; qt++; } retur...

...ements, I get no results even though that phrase exists (no, I don't do a phrase search, just those three words separated by spaces). However if I leave off the "of" I get the expected number of hits. I'm guessing I have to remove the stop words from the query? I default to OP_OR so I would think it would work. Can anyone shed some light on this? Thanks, Jim.

...RDSV(Instruction *i) case SV_FACE: bld.mkInterp(NV50_IR_INTERP_FLAT, def, addr, NULL); if (i->dType == TYPE_F32) { - bld.mkOp2(OP_AND, TYPE_U32, def, def, bld.mkImm(0x80000000)); - bld.mkOp2(OP_XOR, TYPE_U32, def, def, bld.mkImm(0xbf800000)); + bld.mkOp2(OP_OR, TYPE_U32, def, def, bld.mkImm(0x00000001)); + bld.mkOp1(OP_NEG, TYPE_S32, def, def); + bld.mkCvt(OP_CVT, TYPE_F32, def, TYPE_S32, def); } break; case SV_NCTAID: diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp b/src/gallium/drivers/nouvea...

...the change might be implemented ? I had another poke at the patch and have a reworked version which solves the object lifetime issue and works for some simple tests. Can you try it out and see if it works for you? https://trac.xapian.org/ticket/508#comment:13 There are two limitations: * Only OP_OR subqueries are handled. I think supporting these would be a useful step forward by itself, and AIUI it's all you actually need. * Currently the OP_OR subqueries can only have two subqueries of their own. Lifting this restriction needs a bit of work on the new OrPositionList class -...

...gt; is not involved (by the way, proximity of phrases does make sense in this > case, if there is a wishlist somewhere, but it's admittedly not an issue > that most users will be concerned with...). Another case for https://trac.xapian.org/ticket/508 I think. > > * Currently the OP_OR subqueries can only have two subqueries of their own. > > Lifting this restriction needs a bit of work on the new > > OrPositionList class > > - the old patch used a series of pairwise OrPositionList objects, but the > > new patch needs a single one instead...

...ad The most notable changes in this release are: Xapian-core API: * Xapian::Stem now recognises "nb" and "nn" as additional codes for the Norwegian stemmer. * Xapian::QueryParser now correctly parses a wildcarded term in between two other terms (ticket#484). Matcher: * OP_OR could skip a matching document if it decayed to OP_AND or OP_AND_MAYBE during the match in some cases. Fixes ticket#476. * OP_XOR with non-leaf subqueries could skip matching documents in some cases, and OP_XOR of three or more sub-queries could return incorrect weights. Fixes ticket#475....

...d, const string &prefix, bool filter); std::string parse_term(Utf8Iterator &it, const Utf8Iterator &end, @@ -81,7 +83,7 @@ class QueryParser::Internal : public Xapian::Internal::RefCntBase { public: Internal() : stem_action(STEM_NONE), stopper(NULL), - default_op(Query::OP_OR), errmsg(NULL) { } + default_op(Query::OP_OR), errmsg(NULL) { max_wildcard_expansion=0; } Query parse_query(const string & query_string, unsigned int flags, const string & default_prefix); }; -- 1.5.6.3 --=-=-=--

I'm replying to a very old thread (9 years ago) here http://grokbase.com/t/xapian/xapian-discuss/072tprmr6h/php5-query-parsing-bug So not sure if that's going to end up being more or less readable... I have this error : Fatal error: No matching function for overloaded 'new_Query' in /usr/share/php/xapian.php on line 2607 Line 2607 (and surrounding) looks like this and are in

...: subqueries = [] subqueries.extend([xapian.Query(xapian.Query.OP_SCALE_WEIGHT, xapian.Query('S'+term), 4) for term in query_terms]) subqueries.extend([xapian.Query(xapian.Query.OP_SCALE_WEIGHT, xapian.Query('XD'+term), 2) for term in query_terms]) query = xapian.Query(xapian.Query.OP_OR, subqueries) However: 1. It seems overly complicated (and I'm not even sure is correct?) 2. I don't know how to access the terms from a parsed query other than manually parsing and stemming the query string - is there a function for that? Thanks, Katja