similar to: No position.{DB,baseA,baseB}

Most Xapian database files are locked while the database is open, but it seems that .baseA and .baseB files are not, so any other application can delete them (I am talking about the Windows package). Is there a way to protect them as rest of the Xapian database files? Regards, PK

Hi, Is it possible to perform a search without flushing the index? I've got an application that updates the index every 4 hours but I need to be able to search the new data fairly quickly after the index is updated. The problem revolves around the fact that the update is often much less than 10 000 documents so it isn't being flushed until quite a bit latter. I realise I can do a flush

We've had some catastrophic filesystem failures that have left us with corrupted databases with empty files and no backup for about 15TB of our data. Recreating the 15TB from source data backups is possible but will take a very very long time. I'm hoping that, given all of the .DB files are still intact, there my be some way to extract their contents and rebuild the other tables. This

I took one of the examples and tried to run against my database ls -l /data1/mail/db/cur.1 total 1129624 -rw-r--r-- 1 jwl jwl 0 2011-06-09 02:27 flintlock -rw-r--r-- 1 jwl jwl 28 2011-06-09 02:27 iamchert -rwxrwxrwx 1 jwl jwl 7258 2011-06-09 02:27 position.baseA -rwxrwxrwx 1 jwl jwl 7046 2011-06-09 02:27 position.baseB -rwxrwxrwx 1 jwl jwl 474226688 2011-06-09 02:28

hi, i use xapian to index a txt file, it's size is 268M. i take each line as a document, and each line has two field like 13445511 | 111115151. the recored size is 10000000. the XAPIAN_FLUSH_THRESHOLD set 1000000. it takes 1026544ms to index the file, it is more slower than lucene. The lucene speed is about 40000 records per second. code: try { Xapian::WritableDatabase

Hi all, after upgrading xapian I encountered the same problem as described in ticket #645 Read block errors after reopen() in our setup its 100% reproducible after each reopen(). I downgraded again and it seems the problem occurs in Version 1.2.16 and above. in <=1.2.15 everything works fine without seeing this error once. attaches strace shows read ends on FD. strace starts at reopen()

Xapians, I am maintaining about two indexes for my search engines which approximately is each the same size. I would like to share this knowledge with you, since many of you have never seen Xapian index of this size. And of course you can search the index by yourself at - http://myhealthcare.com/ - http://find1friend.com/ I need 2 x 100 million more documents into each index, and I hope it will

Folks, Having trouble getting this to work. OMEGA cgi is not reading my stub file properly because it is trying to read it as a directory instead of a file. Is there an easy fix? Here is a transcript. Thanks, OSC oscar@epsilon:/svr/xapian/beta$ ls -aFl total 21335200 drwxr-xr-x 2 oscar oscar 4096 Aug 6 10:15 ./ drwxr-xr-x 5 oscar oscar 4096 Aug 6 12:59 ../ lrwxrwxrwx 1 oscar

Olly Betts writes: > On Mon, Apr 11, 2016 at 09:54:36AM +0200, Jean-Francois Dockes wrote: > > The question which remains for me is if I should run xapian-compact > > after an initial indexing operation. I guess that this depends on the > > amount of expected updates and that there is no easy answer ? > > I think it's not obvious whether it's a good plan

It took approximately five days, having single process using one core CPU and 6GB of memory to build this giant 607GB single Xapian index, containing 219 million of unique documents (web sites). So far I did not found any other implementation that would enable me to build such a single index containing over 200 million documents, while testing Lucene, Solr, MySQL, Hadoop and Oracle. Probably

Xapian Index 253 million documents = 704G I just build my largest single Xapian index with 253 million unique documents on single server using single hard disk, less that 8G RAM and single processor 2.0 GHz. I do not see any search performance decreases in searching my indexes between 100 million and 250 million, which indicates a good scalability of Xapian and it looks like, I can push it easily

On Wed, Jun 19, 2013, at 03:49 PM, Olly Betts wrote: > On Wed, Jun 19, 2013 at 01:29:16PM +1000, Bron Gondwana wrote: > > The advantage of compact - it runs approximately 8 times as fast (we > > are CPU limited in each case - writing to tmpfs first, then rsyncing > > to the destination) and it takes approximately 75% of the space of a > > fresh database with maximum

I think this is a shining example of how well Xapian works with large document collections. I was just discussing this with my colleagues here and one of the issues that came up is that we'd love Xapian to become really lot more popular but have found that the documentation's a bit difficult to get into, as is the API. So I was wondering: do you have any thoughts on improving this and

I'm happy to be able to announce that Xapian 1.3.4 is now available. Please note that 1.3.x releases are development releases - they are made to encourage earlier and wider use and testing of new and changed code. Our record with 1.1.x was very good - all the bugs I am aware of were either in new features, or were also present in the corresponding 1.0.x release. But if you main concern is

> I think this is a shining example of how well Xapian works with large > document collections. I was just discussing this with my colleagues here > and one of the issues that came up is that we'd love Xapian to become > really lot more popular but have found that the documentation's a bit > difficult to get into, as is the API. I agree. There are a few gotchas, as well

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

Hi, We were running xapian-check on one of our Xapian indexes and it returns the following error: position: baseB blocksize=8K items=809896869 lastblock=2090419 revision=3161 levels=3 root=2084903 Failed to check B-tree: DatabaseError: Items not in sorted order The other tables verify without issue. It looks like our oldest backup of this database (a month old) has the same issue. Searching and

I've some problems converting a xapian db, created with core 1.1.3 (using chert), to the new chert format. I'm using xapian-chert-update, compiled from the core-1.2.4. The conversion seems to run without errors: #./xapian-core-1.2.4/bin/xapian-chert-update old new postlist: Reduced by 33.3333% 16K (48K -> 32K) record: Size unchanged (8K) termlist: doesn't exist position: Size

Hi everyone, I'm trying to build a summary of each document within the search results, and the summary is supposed to be the sentence where the queried term appears in the document. However, I'm not sure about where to start. I mean, should I call the class of XapianDocument and search through the termlist of each document in the Mset or it'll be better if I begin with the

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