similar to: InMemory backend

Xapian (0.7.5) is spitting out this error on a regular basis: org.xapian.errors.DatabaseError: Error reading block 136618: got end of=20= file =A0=A0=A0=A0=A0=A0=A0 at=20 org.xapian.XapianJNI.writabledatabase_repalce_document(Native Method) =A0=A0=A0=A0=A0=A0=A0 at=20 org.xapian.WritableDatabase.replaceDocument(WritableDatabase.java:67) I don't have a gdb backtrace, only the Java

hi, Why xapian don't support memory index/search ? I know there is a method can create memory datebase, like this: Xapian::WritableDatabase db(Xapian::InMemory::open()); *But, if i use these in multithread program, i need create many datebases!!* Xapian::WritableDatabase db1(Xapian::InMemory::open()); //used in thread1 Xapian::WritableDatabase db2(Xapian::InMemory::open()); //used in

I have download source ?1.10? from the internet and build it into lib Then I create a project as the helpdoc said I using vc2005(vc8) The source in my test project is as follow??copy from the helpdoc? #include <xapian.h> #include <iostream> using namespace std; int main(int argc, char **argv) { // Simplest possible options parsing: we just require three or more

There may be some solutions?for example class XAPIAN { *static* int InitDatabase(); //for reading only, do not need lock, but if writing use lock int Search(); //safe in one object, do not need lock }; XIPIAN xp[ THREAD_NUM ]; one thread use one object, they use one database. these can be in memory with one database. 2014-06-24 20:48 GMT+08:00 Olly Betts <olly at survex.com>:

I seem to be seeing cases where I call db.delete_document(somedocid) with no error, then flush() and delete the database object, but the document is still there after process exit. The write lock is normally deleted, so it appears that the database close finished normally. If I then then call delete_document(somedocid) from another command/process, this time it goes away. I've been seeing

Locking of Quartz databases is currently done with a lockfile. This works well from the actual locking side, but the downside is that the lock isn't released if a process doesn't destroy the Xapian::WritableDatabase object. This is made worse because some of the bindings don't call destructors (or don't do it reliably). The obvious alternative is to use actual locking APIs. On

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

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

Please find my inline reply. On 26 January 2015 at 06:56, Olly Betts <olly at survex.com> wrote: > On Sun, Jan 25, 2015 at 06:46:26PM +0500, Saad Ahmed wrote: > > I have been able to successfully build the code. But when I run the > > existing testcases (to verify everthing is working fine), It says 3 out > of > > the six testcases fails. Here is the report of the

Resurrecting an old thread from 2012! Finally got back to working on this. I have been stuck in JavaScript land for too long. Come to find out, on windows, perl does indeed define open to be win32_open and close to be win32_close. This is done in perl/lib/CORE/win3iop.h. So, to get past this problem, I had to modify Xapian.xs to do an #undef of open and close if WIN32 is defined. Also, I had

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

We have: ---------------------------------------------------------------------- typedef unsigned long uint4; ---------------------------------------------------------------------- which on an LP64 system is a lie. If uint4 is used on disk (and it's used in the btree implementation) then it would make the databases unportable, which probably isn't a good idea (unless we already have

Greets, I'm giving a stab at patching the CPAN module to add the missing WritableDatabase::add_spelling and remove_spelling, but need a bit of guidance since I'm coming in cold, and pressed for time (aren't we all). I've modified XS/WritableDatabase.xs and added the two necessary functions, and also added the two basic tests in t/index.t. Compilation completes cleanly, but

Quartz has a QuartzDiskTable class which is a thin wrapper for a pair of Btree objects (or just one if the table is opened readonly): http://www.xapian.org/docs/sourcedoc/html/classQuartzDiskTable.html There's also a QuartzBufferedTable class which adds memory buffering of changes to this: http://www.xapian.org/docs/sourcedoc/html/classQuartzBufferedTable.html However, as of 0.8.0 we now

Hi, Trying to learn Search::Xapian and be better at perl at the same time, I'm stuck, at the DB_CREATE_OR_OPEN error. Perl says this: ~/dev/sandbox/Xapian-perl$ ./Index1-Xap.pl 100-objects-v1.csv db "db" is not exported by the Search::Xapian module Can't continue after import errors at ./Index1-Xap.pl line 7. BEGIN failed--compilation aborted at ./Index1-Xap.pl line 7. What I

Hi, I am a student in Pakistan willing to contribute to Xapian. I have been able to successfully build the code. But when I run the existing testcases (to verify everthing is working fine), It says 3 out of the six testcases fails. Here is the report of the test cases. "... make check-TESTS make[5]: Entering directory `/home/saad/GitProjects/xapian/build/xapian-core/tests' Running

Started a new thread - don't want to hijack the previous one (or carry on hijacking it). On Thu, June 10, 2010 05:17, Olly Betts wrote: >> My issue is that exceptions (ie, "Exception: Key too long: length >> was...") > > You are hitting the Btree key size limit. For flint and chert, this > translates to a term length limit of 245 bytes. > If you are using

Just got this error when replacing (updating) a document in the xapian index (using php bindings): Fatal error: Uncaught exception 'Exception' with message 'DatabaseError: Error reading block 16908825: got end of file' Does anyone know what this means exactly? Alec

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. >

Hi all, I've been toying with xapian (mostly using the Python bindings) and I think I've hit a bug in the TermIterator::skip_to() method (or maybe in QuartzAllTermsList::skip_to()). I've attached a c++ source file that demonstrates the issue. In short, if you have a WritableDatabase, ask for the all-terms TermIterator with db.allterms_begin(), and then skip_to() a word that is itself