Xapian: API Documentation: xapian-core: Xapian::ValueWeightPostingSource Class Reference

# Xapian::ValueWeightPostingSource Class Reference

A posting source which reads weights from a value slot. More...

Inheritance diagram for Xapian::ValueWeightPostingSource:

[legend]

List of all members.

## Public Member Functions
| ValueWeightPostingSource (Xapian::valueno slot_)
| Construct a ValueWeightPostingSource.
Xapian::weight | get_weight () const
| Return the weight contribution for the current document.
ValueWeightPostingSource * | clone () const
| Clone the posting source.
std::string | name () const
| Name of the posting source class.
std::string | serialise () const
| Serialise object parameters into a string.
ValueWeightPostingSource * | unserialise (const std::string &s) const
| Create object given string serialisation returned by serialise().
void | init (const Database &db_)
| Set this PostingSource to the start of the list of postings.
std::string | get_description () const
| Return a string describing this object.

## Detailed Description

A posting source which reads weights from a value slot.

This returns entries for all documents in the given database which have a non empty values in the specified slot. It returns a weight calculated by applying sortable_unserialise to the value stored in the slot (so the values stored should probably have been calculated by applying sortable_serialise to a floating point number at index time).

The upper bound on the weight returned is set using the upper bound on the values in the specified slot, or DBL_MAX if value bounds aren't supported by the current backend.

For efficiency, this posting source doesn't check that the stored values are valid in any way, so it will never raise an exception due to invalid stored values. In particular, it doesn't ensure that the unserialised values are positive, which is a requirement for weights. The behaviour if the slot contains values which unserialise to negative values is undefined.

## Constructor & Destructor Documentation

Xapian::ValueWeightPostingSource::ValueWeightPostingSource | ( | Xapian::valueno | slot_ | ) |

Construct a ValueWeightPostingSource.

Parameters:

  | slot_ | The value slot to read values from.

## Member Function Documentation

ValueWeightPostingSource* Xapian::ValueWeightPostingSource::clone | ( |  | ) | const`[virtual]`

Clone the posting source.

The clone should inherit the configuration of the parent, but need not inherit the state. ie, the clone does not need to be in the same iteration position as the original: the matcher will always call init() on the clone before attempting to move the iterator, or read the information about the current position of the iterator.

This may return NULL to indicate that cloning is not supported. In this case, the PostingSource may only be used with a single-database search.

The default implementation returns NULL.

Note that the returned object will be deallocated by Xapian after use with "delete". It must therefore have been allocated with "new".

Reimplemented from Xapian::PostingSource.

Reimplemented in Xapian::DecreasingValueWeightPostingSource.

std::string Xapian::ValueWeightPostingSource::get_description | ( |  | ) | const`[virtual]`

Return a string describing this object.

This default implementation returns a generic answer. This default it provided to avoid forcing those deriving their own PostingSource subclass from having to implement this (they may not care what get_description() gives for their subclass).

Reimplemented from Xapian::PostingSource.

Reimplemented in Xapian::DecreasingValueWeightPostingSource.

Xapian::weight Xapian::ValueWeightPostingSource::get_weight | ( |  | ) | const`[virtual]`

Return the weight contribution for the current document.

This default implementation always returns 0, for convenience when implementing "weight-less" PostingSource subclasses.

This method may assume that it will only be called when there is a "current document". In detail: Xapian will always call init() on a PostingSource before calling this for the first time. It will also only call this if the PostingSource reports that it is pointing to a valid document (ie, it will not call it before calling at least one of next(), skip_to() or check(), and will ensure that the PostingSource is not at the end by calling at_end()).

Reimplemented from Xapian::PostingSource.

Reimplemented in Xapian::DecreasingValueWeightPostingSource.

void Xapian::ValueWeightPostingSource::init | ( | const Database & | db | ) | `[virtual]`

Set this PostingSource to the start of the list of postings.

This is called automatically by the matcher prior to each query being processed.

If a PostingSource is used for multiple searches, init() will therefore be called multiple times, and must handle this by using the database passed in the most recent call.

Parameters:

  | db | The database which the PostingSource should iterate through.

Note: the database supplied to this method must not be modified: in particular, the reopen() method should not be called on it.

Note: in the case of a multi-database search, a separate PostingSource will be used for each database (the separate PostingSources will be obtained using clone()), and each PostingSource will be passed one of the sub-databases as the db parameter here. The db parameter will therefore always refer to a single database. All docids passed to, or returned from, the PostingSource refer to docids in that single database, rather than in the multi-database.

Reimplemented from Xapian::ValuePostingSource.

Reimplemented in Xapian::DecreasingValueWeightPostingSource.

std::string Xapian::ValueWeightPostingSource::name | ( |  | ) | const`[virtual]`

Name of the posting source class.

This is used when serialising and unserialising posting sources; for example, for performing remote searches.

If the subclass is in a C++ namespace, the namespace should be included in the name, using "::" as a separator. For example, for a PostingSource subclass called "FooPostingSource" in the "Xapian" namespace the result of this call should be "Xapian::FooPostingSource".

This should only be implemented if serialise() and unserialise() are also implemented. The default implementation returns an empty string.

If this returns an empty string, Xapian will assume that serialise() and unserialise() are not implemented.

Reimplemented from Xapian::PostingSource.

Reimplemented in Xapian::DecreasingValueWeightPostingSource.

std::string Xapian::ValueWeightPostingSource::serialise | ( |  | ) | const`[virtual]`

Serialise object parameters into a string.

The serialised parameters should represent the configuration of the posting source, but need not (indeed, should not) represent the current iteration state.

If you don't want to support the remote backend, you can use the default implementation which simply throws Xapian::UnimplementedError.

Reimplemented from Xapian::PostingSource.

Reimplemented in Xapian::DecreasingValueWeightPostingSource.

ValueWeightPostingSource* Xapian::ValueWeightPostingSource::unserialise | ( | const std::string & | s | ) | const`[virtual]`

Create object given string serialisation returned by serialise().

Note that the returned object will be deallocated by Xapian after use with "delete". It must therefore have been allocated with "new".

If you don't want to support the remote backend, you can use the default implementation which simply throws Xapian::UnimplementedError.

Parameters:

  | s | A serialised instance of this PostingSource subclass.

Reimplemented from Xapian::PostingSource.

Reimplemented in Xapian::DecreasingValueWeightPostingSource.

The documentation for this class was generated from the following file:

- xapian/postingsource.h