Result Sets

Question from: Behjat Yousuf Mukhtar Al-Yousuf B.Y.M.Al-Yousuf@READING.AC.UK Thu, 28 Aug 1997 10:25:11 EST

How are result sets created? As a copy of the original records, a table of pointers to the actual database records, or a set of codes that get generated when the result set is requested?

How is modification handled, for a record in a result set?

When a transient result set is "saved" (i.e. via Persistent Result Set Extended Service), is it copied to a task package in the extended services database? how? As a copy of the original records?

How is a persistent result set managed, for example, when a record is modified or deleted?

First it's important to distinguish the physical implementation from the abstract model. How a server chooses to implement result sets is an implementation matter; a result set may be a copy of the database records, a table of pointers, or there may not even be a physical result set -- the server might execute the query every time the result set is referenced, package up and send the requested records, and otherwise immediately discard the results. (However, the Z39.50 result set model does require that a result continue to refer to the same records in the same order; re-executing the search poses a risk to that requirement unless the database is static.) But from the client point of view (i.e. the "abstract" model) the result set is a set of pointers, or more formally, a set of "items", or vectors, where each includes a database name and a pointer to a record within the database.

Regarding modification of a record:

• May the server unilaterally modify a record, even though it may belong to a result set?
  Yes. the server is free to modify a record that belongs to a result set ("belongs to" is used loosely here; more formally: the record is pointed to by a result set) so theoretically, say the client requests record 1, and then subsequently requests record 1 again, the second time it may have changed. There is no direct mechanism provided by Z39.50 to prevent this (though the locking capability provided by the Update Extended Service might be used). When a server does modify a record referenced by a result set, then when the client requests the record, the server might refuse to supply it and instead supply a surrogate diagnostic. But there is no requirement to that effect.
• How may the client request modification of a record in a result set?
  The client should use the Update Extended Service to update or delete a record (whether in a result set or not).

Regarding the question of persistent result sets: as above, how this is implemented is not specified by the protocol, how this is seen by the client is what is relevant. When a transient result set is "saved", presumably it will be restored subsequently into another transient result set. So let's say you save transient result set A (meaning that you create a Persistent Result Set Task Package representing that result set) and then you restore the result set into transient result set B (meaning that you Present the task package, and the server supplies the result set name B, meaning, implicitly, that you may use B to reference the restored result set). Let's say for illustration that you restore it within the same session in which you earlier saved it -- in that case, the result sets A and B should be identical (if a record has changed according to result set A, then it has also changed according to result set B), if the server has implemented result sets according to the abstract model, i.e via pointers. But there is no requirement to do so. The server might instead "save" the result set by actually copying the records, in which case the two result set may not be identical. The standard does not specify how the server is to actually save and/or store the database records, or how similar to the original records the restored records must be.

Concerning the management of a persistent result set: When a result set is saved, a task package is created in the ES database that represents the result set. However, the result set itself (i.e. the content) is not part of the ES database, that is, result set records from the saved result set are not directly retrievable. They may be retrieved only by the method described above, that is, by restoring the saved result set to a transient result set (as described above) and then Presenting from that transient result set. So a persistent result set cannot be directly modified. You can save a result set, and somebody may subsequently restore it, modify it, and save it again. But the management aspects of this are not within the scope of the protocol, except to the extent that the Extended Services facility does provide "permissions" capability for use by an administrator. On the other hand, a persistent result set may be directly deleted -- you can simply delete the task package (using the delete function on an extended services request) which in effect deletes the persistent result set.