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

olly wrote:
> SVN root:       svn://svn.xapian.org/xapian
> Changes by:     olly
> Revision:       9092
> Date:           2007-06-30 15:16:16 +0100 (Sat, 30 Jun 2007)
> 
> Log message (2 lines):
> api/omdocument.cc,common/document.h,include/xapian/document.h:
> Add Xapian::Document::get_docid() method.
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.

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

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.

This would also be useful for the ErrorHandler mechanism (for reporting 
which database in a remote situation a failure occurred in).

-- 
Richard

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