similar to: xapian-compact seg faulting & Re: Error msg xapian-compact: The revision being read has been discarded - you should call Xapian::Database::reopen() and retry the operation

Folks, OK found it, omega.cc looks for multiple DB definitions and adds it to the search list. If the dbs are only one directory lower (e.g. not in default as in beta/default, but only "beta"), then modifying database_dir setting as follows will work: database_dir /svr/hda1/xapian then, ./omega.cgi 'P=pda' FMT='xml' DB="beta" DB="gamma"

hi, I'm using Xapian on Windows with large files. My index directory is about 65 607 466 693 bytes: 2007-01-30 09:28 17 position_baseA 2007-01-30 10:06 17 position_baseB 2007-01-23 14:18 0 position_DB 2007-01-30 10:06 360 496 postlist_baseB 2007-01-30 10:06 23 623 852 032 postlist_DB 2007-01-30 10:06 88 432

Flint failed to deliver indexing performance to Quartz. I am proposing to remove Flint as default database and place Quartz database back as default. The catch is not that Flint database is smaller and faster during searches then Quartz database as developers were concerning when were measuring and neglecting to measure performance when creating the large indexes. The truth is that Flint

Hi, I configured XAPIAN 1.0.1 and OMEGA 1.0.1. on my development machine (first removed the old ones). I recreated my databases (both quartz and flint) and tried to run original queries against the databases created by the new versions. I'm getting empty result sets from OMEGA. If I use the delve tool I actually see that the records are created fine. No log files are written as far as I

olly wrote: > SVN root: svn://svn.xapian.org/xapian > Changes by: olly > Revision: 8351 > Date: 2007-04-23 01:44:44 +0100 (Mon, 23 Apr 2007) > > Log message (2 lines): > backends/flint/flint_version.cc: Update the flint format version > since older flint versions can't read compressed tags. Am I correct in assuming that this means that when

Hello :-) There was probably no good reason to do this build but the Debian 6.0 Squeeze repo version was 1.2.3, we needed 1.2.4 and I didn't think of using the package from unstable. Arch: x86_64 Platform: Linux 2.6 Debian 6.0 (Squeeze) Compiler: gcc version 4.4.5 (Debian 4.4.5-8) Version: 1.2.4 Status: no known problems Source: http://oligarchy.co.uk/xapian/1.2.4/xapian-core-1.2.4.tar.gz

Report by Eric Lindblad 14-09-2015 http://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".

Hi everyone, I'm having a problem with xapian (the matchspy branch, with Python bindings) on Solaris 10 / SPARC. Users can run queries for a few hours with no problems, then it returns "inflate failed (invalid code lengths set)" to Python and dumps core. gdb reports: #0 0xfe6dc910 in inflate_table () from /usr/lib/libz.so.1 #1 0xfe6d9d6c in inflate () from /usr/lib/libz.so.1 #2

olly wrote: > Log message (6 lines): > backends/flint/flint_database.cc: Delete the corresponding entry > (if any) from doclens in delete_document(). Add assertion to > add_document_() that the corresponding entry in doclens isn't > already set, but in a non-debug build overwrite any existing > entry as that's more likely to be correct. >

On Tue, Jan 02, 2007 at 03:55:59PM +0000, richard wrote: > * backends/quartz/btree.cc,backends/flint/flint_io.h: Patches from > Charlie Hull to allow 2GB+ index files work when compiled using > Visual C++. I suspect that xapian-compact.cc (and quartzcompact.cc if you can be bothered) will also need fixing since they use off_t. You need to make sure that the stat() function called

On Mon, Apr 09, 2007 at 11:26:44AM +0100, richard wrote: > backends/flint/flint_database.cc: Fix bug with document lengths > in replace document. Was using doclens.insert() to set the new > document length, but this has no effect if the entry already > exists. Argh! That issue has bitten us at least once before. I'll audit all uses of insert to see if there are any other

Hello, I'm using Xapian 1.0.2 (flint) and matching Search::Xapian. I'm getting: terminate called after throwing an instance of 'Xapian::DocNotFoundError', which dumps core. at first it was after adding my 2nd document (to an empty db, although I don't know if that has any bearing) to the database with a replace_document() call. I shifted the first document off the

olly wrote: > SVN root: svn://svn.xapian.org/xapian > Changes by: olly > Revision: 9092 > Date: 2007-06-30 15:16:16 +0100 (Sat, 30 Jun 2007) > > Log message (2 lines): > api/omdocument.cc,common/document.h,include/xapian/document.h: > Add Xapian::Document::get_docid() method. I was thinking that it would probably be useful to have a

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

I've uploaded Xapian 1.0.19 (including Search::Xapian 1.0.19.0), which as usual you can download from: http://xapian.org/download The most notable changes in this release are: QueryParser: * Fix memory leak if Database throws an exception during parsing. Flint backend: * Updating positional information for a document optimised a little. Search::Xapian: * Wrap

I've uploaded Xapian 1.0.18 (including Search::Xapian 1.0.18.0), which as usual you can download from: http://xapian.org/download The most notable changes in this release are: QueryParser: * Improve support for languages such as Burmese which use Unicode enclosing mark and combining spacing mark characters. Flint backend: * When updating documents, don't update posting entries

The attached adds XS wrappers for back-ends: use Search::Xapian; my $db = Search::Xapian::Remote::open_writable( "biggles", 10252 ); my $db = Search::Xapian::Flint::open_writable( "testdb" ); my $db = Search::Xapian::InMemory::open_writable(); All the best, Tim. -------------- next part -------------- A non-text attachment was scrubbed... Name: xapian_backend_patch.diff

Thanks Olly, I have given flint a go -and it is generally much quicker (once it has loaded the cache -that process still takes minutes). Flint actually seems tro do some caching whereas quartz just seemed to hit the disc constantly. Generally I've been running it on a machine with 5G of memory -but it has to contend with other processes for resources, I have also run it on its own on a 1G

We have an urgent problem that we've been spending hours on to no avail. We have a RHEL 5.2 server that is running Samba 3.2.8 and was set up for domain authentication against our PDC. It was running fine until I decided to try and change it to "ads" authentication. I then realized that we needed to keep it on "domain" because of the version of Clearcase we have on the

I am not sure if this first post made it to the list, but I wanted to post the resolution, which was very simple and something I had documented but buried and I had forgotten about it. All these problems went away when I joined the domain using Samba's version of "net", not Redhat's. If you use Redhat's version, it looks like it joins the domain but it really doesn't