3. Result sets
Prev | Chapter 3. ZOOM | Next

## 3. Result sets

The result set object is a container for records returned from a target.

         ZOOM_resultset ZOOM_connection_search(ZOOM_connection, ZOOM_query q);

         ZOOM_resultset ZOOM_connection_search_pqf(ZOOM_connection c,
                                                   const char *q);
         void ZOOM_resultset_destroy(ZOOM_resultset r);

Function `ZOOM_connection_search` creates a result set given a connection and query. Destroy a result set by calling `ZOOM_resultset_destroy`. Simple clients may using PQF only may use function `ZOOM_connection_search_pqf` in which case creating query objects is not necessary.

         void ZOOM_resultset_option_set(ZOOM_resultset r,
                                        const char *key, const char *val);

         const char *ZOOM_resultset_option_get(ZOOM_resultset r, const char *key);

         size_t ZOOM_resultset_size(ZOOM_resultset r);

Functions `ZOOM_resultset_options_set` and `ZOOM_resultset_get` sets and gets an option for a result set similar to `ZOOM_connection_option_get` and `ZOOM_connection_option_set`.

The number of hits also called result-count is returned by function `ZOOM_resultset_size`.

Table 3.2. ZOOM Result set Options

Option | Description | Default
--- | --- | ---
start | Offset of first record to be retrieved from target. First record has offset 0 unlike the protocol specifications where first record has position 1. This option affects ZOOM_resultset_search and ZOOM_resultset_search_pqf and must be set before any of these functions are invoked. If a range of records must be fetched manually after search, function ZOOM_resultset_records should be used. | 0
count | Number of records to be retrieved. This option affects ZOOM_resultset_search and ZOOM_resultset_search_pqf and must be set before any of these functions are invoked. | 0
presentChunk | The number of records to be requested from the server in each chunk (present request). The value 0 means to request all the records in a single chunk. (The old `step` option is also supported for the benefit of old applications.) | 0
elementSetName | Element-Set name of records. Most targets should honor element set name `B` and `F` for brief and full respectively. | none
preferredRecordSyntax | Preferred Syntax, such as `USMARC`, `SUTRS`, etc. | none
schema | Schema for retrieval, such as `Gils-schema`, `Geo-schema`, etc. | none
setname | Name of Result Set (Result Set ID). If this option isn't set, the ZOOM module will automatically allocate a result set name. | default
rpnCharset | Character set for RPN terms. If this is set, ZOOM C will assume that the ZOOM application is running UTF-8. Terms in RPN queries are then converted to the rpnCharset. If this is unset, ZOOM C will not assume any encoding of RPN terms and no conversion is performed. | none

For servers that support Search Info report, the following options may be read using `ZOOM_resultset_get`. This detailed information is read after a successful search has completed.

This information is a list of of items, where each item is information about a term or subquery. All items in the list are prefixed by `SearchResult.` `no` where no presents the item number (0=first, 1=second). Read `searchresult.size` to determine the number of items.

Table 3.3. Search Info Report Options

Option | Description
--- | ---
searchresult.size | number of search result entries. This option is-nonexistant if no entries are returned by the server.
searchresult.`no`.id | sub query ID
searchresult.`no`.count | result count for item (number of hits)
searchresult.`no`.subquery.term | subquery term
searchresult.`no`.interpretation.term | interpretation term
searchresult.`no`.recommendation.term | recommendation term

### 3.1. Z39.50 Protocol behavior

The creation of a result set involves at least a SearchRequest - SearchResponse protocol handshake. Following that, if a sort criteria was specified as part of the query, a SortRequest - SortResponse handshake takes place. Note that it is necessary to perform sorting before any retrieval takes place, so no records will be returned from the target as part of the SearchResponse because these would be unsorted. Hence, piggyback is disabled when sort criteria are set. Following Search - and a possible sort - Retrieval takes place - as one or more Present Requests/Response pairs being transferred.

The API allows for two different modes for retrieval. A high level mode which is somewhat more powerful and a low level one. The low level is enabled when searching on a Connection object for which the settings `smallSetUpperBound`, `mediumSetPresentNumber` and `largeSetLowerBound` are set. The low level mode thus allows you to precisely set how records are returned as part of a search response as offered by the Z39.50 protocol. Since the client may be retrieving records as part of the search response, this mode doesn't work well if sorting is used.

The high-level mode allows you to fetch a range of records from the result set with a given start offset. When you use this mode the client will automatically use piggyback if that is possible with the target and perform one or more present requests as needed. Even if the target returns fewer records as part of a present response because of a record size limit, etc. the client will repeat sending present requests. As an example, if option `start` is 0 (default) and `count` is 4, and `piggyback` is 1 (default) and no sorting criteria is specified, then the client will attempt to retrieve the 4 records as part the search response (using piggyback). On the other hand, if either `start` is positive or if a sorting criteria is set, or if `piggyback` is 0, then the client will not perform piggyback but send Present Requests instead.

If either of the options `mediumSetElementSetName` and `smallSetElementSetName` are unset, the value of option `elementSetName` is used for piggyback searches. This means that for the high-level mode you only have to specify one elementSetName option rather than three.

### 3.2. SRU Protocol behavior

Current version of YAZ does not take advantage of a result set id returned by the SRU server. Future versions might do, however. Since, the ZOOM driver does not save result set IDs any present (retrieval) is transformed to a SRU SearchRetrieveRequest with same query but, possibly, different offsets.

Option `schema` specifies SRU schema for retrieval. However, options `elementSetName` and `preferredRecordSyntax` are ignored.

Options `start` and `count` are supported by SRU. The remaining options `piggyback`, `smallSetUpperBound`, `largeSetLowerBound`, `mediumSetPresentNumber`, `mediumSetElementSetName`, `smallSetElementSetName` are unsupported.

SRU supports CQL queries, not PQF. If PQF is used, however, the PQF query is transferred anyway using non-standard element `pQuery` in SRU SearchRetrieveRequest.

SOLR queries has to be done in SOLR query format.

Unfortunately, SRU or SOLR does not define a database setting. Hence, `databaseName` is unsupported and ignored. However, the path part in host parameter for functions `ZOOM_connecton_new` and `ZOOM_connection_connect` acts as a database (at least for the YAZ SRU server).

Prev | Up | Next
2. Queries | Home | 4. Records