[Xapian-devel] Re: [Xapian-commits] 9092: trunk/xapian-core/ trunk/xapian-core/api/ trunk/xapian-core/common/ trunk/xapian-core/include/xapian/

[Olly Betts]

On Sat, Jun 30, 2007 at 06:27:01PM +0100, Richard Boulton wrote:
> I was thinking that it would probably be useful to have a 
> Xapian::Document::get_database_name() method, to allow the database that 
> a document came from (in a multi-database situation) to be obtained.

What do you see this new method being useful for?  Not saying it isn't
useful, but I don't see a use immediately - in the case of wanting to
be able to "refile" a modified document, there can only be one database
(we don't support writable multi-databases).

It might be better to simply return the "multi-docid" here rather than
introduce API complications.

> For a Flint database, this would return the path that was used to open 
> the database.  For a remote (TCP) database, it would return a string 
> indicating the host and port that the database is at (probably in a 
> pseudo URL form something like "remotetcp://host:port/"), and something 
> similar for a remote progsrv database.  Not sure what an inmemory one 
> would return...

We already have a "textual form" for most database backends - that used
in a stub database file.  There isn't one for InMemory though.

> Alternatively, databases could have a new "set_name()" method which sets 
> the name to return (possibly with something like the above as the 
> default) to avoid having to do long string compares to work out which 
> database a document came from.

Note that long string comparisons are only really slower than short ones
if there are a lot of non-matches with a long prefix that matches the
sought string.

But if we want to be able to indicate the individual database, I think
it would be more natural to simply return a Database object.  That
would work with InMemory() databases and avoid the need for tracking the
list of databases separately and then working out which one matches the
string returned.

Cheers,
    Olly