Xapian devel - Sep 2004 - InMemory backend

I've just added a feature test for the new WritableDatabase methods -
replace_document() and delete_document() with a unique term.  This
initially failed for inmemory due to bugs in the backend.  They weren't
trivial to fix and my initial attempt at a fix caused other tests to
fail.

I've come to the conclusion that the code there probably should be
retired.  It was written early on for testing purposes, so it isn't
coded with efficiency in mind and doesn't fully anticipate what is now
built above it.

It is useful to be able to open small temporary databases in memory,
but I think from a performance and from a code maintenance point of
view we'd be better off providing an alternative lower level for
quartz which uses memory instead of disk to store the Btree.  Or
perhaps replaces the Btree with a suitable map<>, but I think
a lower level is more appropriate.

Thoughts?

Cheers,
    Olly

On Thu, Sep 09, 2004 at 02:28:58AM +0100, Olly Betts wrote:
> It is useful to be able to open small temporary databases in memory,
> but I think from a performance and from a code maintenance point of
> view we'd be better off providing an alternative lower level for
> quartz which uses memory instead of disk to store the Btree.  Or
> perhaps replaces the Btree with a suitable map<>, but I think
> a lower level is more appropriate.
At what layer does Quartz start caring about files? Immediately above
the btree manager, or is there still a higher mechanism that abstracts
that?

J

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  james at tartarus.org                               uncertaintydivision.org

On Thu, 2004-09-09 at 02:28, Olly Betts wrote:
> It is useful to be able to open small temporary databases in memory,
> but I think from a performance and from a code maintenance point of
> view we'd be better off providing an alternative lower level for
> quartz which uses memory instead of disk to store the Btree.  Or
> perhaps replaces the Btree with a suitable map<>, but I think
> a lower level is more appropriate.
I think this is appropriate - it should reduce code size and complexity,
and has the potential to be a lot more memory efficient than the current
InMemory databases.

For what it's worth, this is the approach taken by SQLite to implement
in-memory databases.

-- 
Richard