search for: quartz_database

...he 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. > backends/quartz/quartz_database.cc: Ditto. This fixes an assertion error I was seeing with remote database with replacedoc4 with builds with assertions turned on. All tests now pass for me in both debug and non-debug builds (and it looks like remote databases now support essentially all methods that local databases do, yay!)...

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

..._log.o .libs/libxapian.lax/libbackend.a/inmemory_alltermslist.o .libs/libxapian.lax/libbackend.a/quartz_postlist.o .libs/libxapian.lax/libbackend.a/btree.o .libs/libxapian.lax/libbackend.a/inmemory_positionlist.o .libs/libxapian.lax/libbackend.a/flint_positionlist.o .libs/libxapian.lax/libbackend.a/quartz_database.o .libs/libxapian.lax/libbackend.a/flint_values.o .libs/libxapian.lax/libbackend.a/quartz_positionlist.o .libs/libxapian.lax/libbackend.a/multi_alltermslist.o .libs/libxapian.lax/libbackend.a/multi_termlist.o .libs/libxapian.lax/libbackend.a/flint_record.o .libs/libxapian.lax/libbackend.a/flint_all...