virt_db — Metaproxy Virtual Databases Module
This filter allows one Z39.50 database to be be mapped to another target; or even multiple targets.
The configuration of virt_db consists of zero or more
<virtual> elements, each describing the
Z39.50 virtual database recognized.
The name of the database is the text content of the
<database> element which should be
first element inside the virtual section.
For Metaproxy 1.0.20 and later, the database is treated as a glob pattern. This allows operators * (any number of any character) and ? (any single character). The virtual sections are inspected in the order given. The first matching virtual database is used.
Following that is one or more <target>
elements, with the identifier of each target that the virtual database
maps to. If a database is given for a target (following a slash), that
database name is used as Z39.50 database for this target. If the
database is omitted for the target, the original (virtual) database
is used as Z39.50 database.
If multiple targets are given, that has special meaning depending on the filter following virt_db. If the following filter is load_balance, then the load_balance filter will load balance between the targets given (assuming they serve same content). If the following filter is multi, then results will be merged from all targets instead.
The z3950_filter, on the other hand, does not support multiple targets.
For <virtual> a route may be given as
an attribute. This will make Metaproxy route traffic to the route
given. Note that virtual databases may not be combined if all
databases do not result in the same routing.
# Metaproxy XML config file schemas
#
# Copyright (C) Index Data
# See the LICENSE file for details.
namespace mp = "http://indexdata.com/metaproxy"
filter_virt_db =
attribute type { "virt_db" },
attribute id { xsd:NCName }?,
attribute name { xsd:NCName }?,
element mp:pass-vhosts { xsd:boolean }?,
element mp:virtual {
attribute route { xsd:NCName }?,
element mp:database { xsd:string },
element mp:target { xsd:string }+
}*
Consider this virt_db configuration:
<filter type="virt_db">
<virtual>
<database>db1</database>
<target>localhost:9999/Default</target>
</virtual>
<virtual>
<database>db2</database>
<target>z3950.indexdata.com/gils</target>
</virtual>
<virtual>
<database>combined</database>
<target>z3950.indexdata.com/gils</target>
<target>localhost:9999/Default</target>
</virtual>
<virtual route="special">
<database>db3</database>
<target>z3950.indexdata.com/special</target>
</virtual>
<virtual>
<database>*</database><!-- default -->
<target>localhost:9999</target><!-- database not altered -->
</virtual>
</filter>
This will offer 4 databases, db1,
db2, combined and
db3. If a Z39.50 specifies db1
and db2, that will have the same effect as specifying
the single databases combined.
Since db3 routes differently from the other databases,
this database may not be combined with the others.