search for: op_phrase

Hi all, I've come across an issue caused when I try to set the query parser's default op to OP_PHRASE: Xapian raises an Unimplemented Error if the query contains hyphenated words or other terms that implicitly generate a phrase. This can be shown with the following Python extract: >>> from xapian import * >>> qp = QueryParser() >>> qp.set_default_op(Query.OP_PHRASE) &gt...

Hi, 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 a query with the error message. OP_NEAR and OP_PHRASE only currently support leaf subqueries Because Recoll expands the terms to their stem siblings at query time, its NEAR queries are affected by the change (no stemming is used with PHRASE queries, so these are unaffected). Of course, it would be possible to effect the distribution at the applicati...

Hi All, I used the OP_NEAR operator for queryparser, and when I searched for "apple store" from my own collection, the query is parsed as "Zappl:(pos=1) NEAR 11 Zstore:(pos=2)" but retrieved nothing. However, if I type in "Apple Store", the query is parsed as Xapian::Query((apple:(pos=1) NEAR 11 store:(pos=2))) and some results are showed. I'm not sure whether

On Sun, Sep 30, 2018 at 09:05:25AM -0300, David Bremner wrote: > if (str.find (' ') != std::string::npos) > query_str = '"' + str + '"'; > else > query_str = str; > > return parser.parse_query (query_str, NOTMUCH_QUERY_PARSER_FLAGS, term_prefix); I wouldn't recommend trying to generate strings to feed to

.../www.ericlindblad.blogspot.com cf: http://permalink.gmane.org/gmane.comp.search.xapian.general/9880 The 'gmake check' compile error on xapian-core-1.2.21/tests/api_backend.cc was resolved by the modification (at the suggestion of a mailing-list member) of the offending string from "q.OP_PHRASE" to "Xapian::Query::OP_PHRASE". 'gmake check' results ./apitest backend none: 57 tests passed, 1 failed. ./apitest backend inmemory: 220 tests passed, 6 failed, 8 skipped. ./apitest backend flint: 293 tests passed, 5 failed, 2 skipped. ./apitest backend multi_flint: 153 tes...

Report by Eric Lindblad 13-09-2015 http://www.ericlindblad.blogspot.com cf: http://comments.gmane.org/gmane.comp.search.xapian.general/9862 I ported xapian-core-1.2.21 to Interix today having disabled the default chert and development brass backends, using flint, which was the 1.0.x series' default, which ships with the 1.2.x series; the disabling do to an unresolved 'ambiguous

Hi. I'm using Xapian, and I'm having some difficulty doing the following: I have db with a field "name": 1 with name="foo" 2 with name="foo bar" 3 with name="foo bar for you u2". I index this in the database using a prefix FNAME indicating the field where the strings belong to. delve -a returns something like FNAMEfoo FNAMEbar ... My question

...ill 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:smith:(pos=2)))) i.e :(AUT1:john PHRASE AUT1:smith) OR (AUT2:john PHRASE AUT1:smith) OR (AUT2:j...

...eries (owing to the dependency on C++11 support), but that on the latter probably realistically something newer some earlier cited code changes from my other posts cf: http://permalink.gmane.org/gmane.comp.search.xapian.general/9883 /xapian-core-1.2.21/tests/api_backend.cc - Xapian::Query q(q.OP_PHRASE, qterms, qterms + 2, 5); + Xapian::Query q(Xapian::Query::OP_PHRASE, qterms, qterms + 2, 5); cf: http://permalink.gmane.org/gmane.comp.search.xapian.general/9880 /xapian-core-1.2.21/net/tcpclient.cc #include <cmath> #include <cstring> #ifndef __WIN32__ # include "safenetdb...

Hi all. We are trying to use Xapian to index the titles of around ten million documents (music catalogue) and then do auto-complete style search on this index. After poking around we can't quite get the combination of QueryParser flags and search query that will give back the results we want. The closest we have can take a very long time (because it is searching for, and building a list of,

...ian/query.h,api/omqueryinternal.cc: Fix query Index: api/omqueryinternal.cc =================================================================== --- api/omqueryinternal.cc (revision 7553) +++ api/omqueryinternal.cc (working copy) @@ -54,6 +54,7 @@ case Xapian::Query::OP_NEAR: case Xapian::Query::OP_PHRASE: case Xapian::Query::OP_ELITE_SET: + case Xapian::Query::OP_MATCH_NOTHING: return 0; case Xapian::Query::OP_FILTER: case Xapian::Query::OP_AND_MAYBE: @@ -70,6 +71,7 @@ { switch (op) { case Xapian::Query::Internal::OP_LEAF: + case Xapian::Query::OP_MATCH_NOTHING:...

...en lot of work done that yield inconsistent results. What I am trying to point out is that we need start to think about using natural language processing when placing infrastructure for Xapian. So far we have the following OP_AND, OP_AND_MAYBE, OP_AND_NOT, OP_ELITE_SET, OP_FILTER, OP_NEAR, OP_OR, OP_PHRASE, OP_VALUE_RANGE, OP_XOR search operators and we could add one more OP_NLP. What we can do now is to implement OP_NLP to tagged nouns, adjectives, adverbs, punctuations, foreign words etc. Calculate relation between them and assign boost value to the most occurred terms in query for example noun....

...se fixes a number of bugs and improves efficiency in one case. Notable changes in this release: * WritableDatabase::remove_spelling() now works properly. * The QueryParser now handles scripts which use NON_SPACING_MARK Unicode characters (such as Arabic) better. * Distribution of OP_NEAR and OP_PHRASE over a non-leaf subquery is improved. * The database locking code no longer leaves a zombie child process when the database is already locked. For a more detailed overview see: http://trac.xapian.org/wiki/ReleaseOverview/1.0.12 The full lists of user-visible changes are linked to from there,...

Hi All, I know that from version 1.2.6, if default_op is OP_NEAR or OP_PHRASE then stemming of the terms is disabled, since positional information isn't indexed for stemmed terms by default. However, I would like to try using OP_NEAR as default_op with stemming because I think the near operator is somehow different from exact phrase. Then I wanna see how the search resul...

Hi, I'd like to know how we can choose the distance between two words that we search in a text. I know there is an "op_near" operator but I don't know how I can specified that the number of words between the two specified words should not exceed 10 or 20 or x words. I'm really sorry for my terrible English, I hope I'm understandable!

...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 a query with the error message. > > OP_NEAR and OP_PHRASE only currently support leaf subqueries > > Because Recoll expands the terms to their stem siblings at query time, its > NEAR queries are affected by the change (no stemming is used with PHRASE > queries, so these are unaffected). > > Of course, it would be possible to effect the...

...- 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#comment:8 * OP_AND_NOT: https://trac.xapian.org/ticket/508#comment:11 I've added a note about OP_NEAR/OP_PHRASE. > > The code I pushed before wouldn't handle an OR of more than two things, > > so you couldn't do a 3+-way stem expansion: > > > > (text OR texts) NEAR (search OR searches OR searched OR searching) > > > > But I've just pushed an update...

...apian::weight cutoff); void set_elite_set_size(Xapian::termcount size); Xapian::termcount set_length(Xapian::termcount qlen); The private non-const methods are only used during construction, so they're not a problem. I tend to favour (b). The first three are tied to particular OPs (OP_NEAR/OP_PHRASE, OP_WEIGHT_CUTOFF, and OP_ELITE_SET respectively) so are perhaps cleaner that way anyway. The last is more awkward as a constructor parameter - it would perhaps be better replaced by an optional parameter to Enquire::set_query(). This is an API change (unlike (a)), but not one which is hard to up...

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"),

...es. 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. * OP_OR is now more efficient if a subquery is potentially expensive (e.g. OP_VALUE_RANGE, OP_NEAR, OP_PHRASE, PostingSource). A 10-fold speed-up with OP_VALUE_RANGE has been observed. Build System: * Install files to make Xapian easier to use with cmake. Portability * On x86 processors, Xapian now defaults to using SSE2 FP instructions. This avoids issues with excess precision and it a bit faste...