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.
Note: 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 no even a uniform notion of what a field is 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 obejcts 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;
|