When using this method you construct an (almost) arbitrary, internal record key based on the contents of the record itself and other system information. If you have a group of records that explicitly associates an ID with each record, this method is convenient. For example, the record format may contain a title or a ID-number - unique within the group. In either case you specify the Z39.50 attribute set and use-attribute location in which this information is stored, and the system looks at that field to determine the identity of the record.
As before, the record ID is defined by the recordId
setting in the configuration file. The value of the record ID specification
consists of one or more tokens separated by whitespace. The resulting
ID is represented in the index by concatenating the tokens and
separating them by ASCII value (1).
There are three kinds of tokens:
The token refers to a key that is
extracted from the record. The syntax of this token is
( set ,
use ),
where set is the
attribute set name use is the
name or value of the attribute.
The system variables are preceded by
$
and immediately followed by the system variable name, which may one of
Group name.
Current database specified.
Record type.
A string used as part of the ID — surrounded by single- or double quotes.
For instance, the sample GILS records that come with the Zebra
distribution contain a unique ID in the data tagged Control-Identifier.
The data is mapped to the BIB-1 use attribute Identifier-standard
(code 1007). To use this field as a record id, specify
(bib1,Identifier-standard) as the value of the
recordId in the configuration file.
If you have other record types that uses the same field for a
different purpose, you might add the record type
(or group or database name) to the record id of the gils
records as well, to prevent matches with other types of records.
In this case the recordId might be set like this:
gils.recordId: $type (bib1,Identifier-standard)
(see Chapter 9, GRS-1 Record Model and Filter Modules for details of how the mapping between elements of your records and searchable attributes is established).
As for the file record ID case described in the previous section,
updating your system is simply a matter of running
zebraidx
with the update command. However, the update with general
keys is considerably slower than with file record IDs, since all files
visited must be (re)read to discover their IDs.
As you might expect, when using the general record IDs
method, you can only add or modify existing records with the
update command.
If you wish to delete records, you must use the,
delete command, with a directory as a parameter.
This will remove all records that match the files below that root
directory.