A ZOOM::record object represents a chunk of data
from a resultSet returned from a server.
The class has this declaration:
class record {
public:
~record ();
enum syntax {
UNKNOWN, GRS1, SUTRS, USMARC, UKMARC, XML
};
record *clone () const;
syntax recsyn () const;
const char *render () const;
const char *rawdata () const;
};
Records returned from Z39.50 servers are encoded using a record
syntax: the various national MARC formats are commonly used for
bibliographic data, GRS-1 or XML for complex structured data, SUTRS
for simple human-readable text, etc. The
record::syntax enumeration specifies constants
representing common record syntaxes, and the
recsyn() method returns the value corresponding
to the record-syntax of the record on which it is invoked.
Because this interface uses an enumeration, it is difficult to extend to other record syntaxes - for example, DANMARC, the MARC variant widely used in Denmark. We might either grow the enumeration substantially, or change the interface to return either an integer or a string.
The simplest thing to do with a retrieved record is simply to
render() it. This returns a human-readable, but
not necessarily very pretty, representation of the contents of the
record. This is useful primarily for testing and debugging, since
the application has no control over how the record appears.
(The application must not
delete the returned string - it is ``owned'' by
the record object.)
More sophisticated applications will want to deal with the raw data
themselves: the rawdata() method returns it.
Its format will vary depending on the record syntax: SUTRS, MARC
and XML records are returned ``as is'', and GRS-1 records as a
pointer to their top-level node, which is a
Z_GenericRecord structure as defined in the
<yaz/z-grs.h> header file.
(The application must not
delete the returned data - it is ``owned'' by
the record object.)
Perceptive readers will notice that there are no methods for access to individual fields within a record. That's because the different record syntaxes are so different that there is not even a uniform notion of what is a field across them all, let alone a sensible way to implement such a function. Fetch the raw data instead, and pick it apart ``by hand''.
The record objects returned from
resultSet::getRecord() are ``owned'' by the
result set object: that means that the application is not
responsible for deleteing them - each
record is automatically deallocated when the
resultSet that owns it is
deleted.
Usually that's what you want: it means that you can easily fetch a record, use it and forget all about it, like this:
resultSet rs(conn, query);
cout << rs.getRecord(0)->render();
But sometimes you want a record to live on past
the lifetime of the resultSet from which it was
fetched. In this case, the clone(f) method can
be used to make an autonomous copy. The application must
delete it when it doesn't need it any longer:
record *rec;
{
resultSet rs(conn, query);
rec = rs.getRecord(0)->clone();
// `rs' goes out of scope here, and is deleted
}
cout << rec->render();
delete rec;