From 878a848853ad9e4f63da983476161613e114672d Mon Sep 17 00:00:00 2001 From: Marc Cromme Date: Fri, 30 Jun 2006 10:46:26 +0000 Subject: [PATCH] rewrite of extended service section to add new information from Sebastian, triggered to a question from Eric Lease Morgan and Joshua Ferraro --- doc/administration.xml | 258 +++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 212 insertions(+), 46 deletions(-) diff --git a/doc/administration.xml b/doc/administration.xml index 7303d30..912f216 100644 --- a/doc/administration.xml +++ b/doc/administration.xml @@ -1,5 +1,5 @@ - + Administrating Zebra + + + + + + Extended services in the Z39.50 protocol + + + The Z39.50 standard allowes + servers to accept special binary extended services + protocol packages, which may be used to insert, update and delete + records into servers. These carry control and update + information to the servers, which are encoded in seven package fields: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Extended services Z39.50 Package Fields
ParameterValueNotes
type'update'Must be set to trigger extended services
actionstring + Extended service action type with + one of four possible values: recordInsert, + recordReplace, + recordDelete, + and specialUpdate +
recordXML stringAn XML formatted string containing the record
syntax'xml'Only XML record syntax is supported
recordIdOpaquestring + Optional client-supplied, opaque record + identifier used under insert operations. +
recordIdNumber positive numberZebra's internal system number, only for update + actions. +
databaseNamedatabase identifier + The name of the database to which the extended services should be + applied. +
+ + + + The action parameter can be any of + recordInsert (will fail if the record already exists), + recordReplace (will fail if the record does not exist), + recordDelete (will fail if the record does not + exist), and + specialUpdate (will insert or update the record + as needed). + + + During a recordInsert action, the + usual rules for internal record ID generation apply, unless an + optional recordIdNumber Zebra internal ID or a + recordIdOpaque string identifier is assigned. + The default ID generation is + configured using the recordId: from + zebra.cfg. + + + + The actions recordReplace or + recordDelete need specification of the additional + recordIdNumber parameter, which must be an + existing Zebra internal system ID number, or the optional + recordIdOpaque string parameter. + + + + When retrieving existing + records indexed with GRS indexing filters, the Zebra internal + ID number is returned in the field + /*/id:idzebra/localnumber in the namespace + xmlns:id="http://www.indexdata.dk/zebra/", + where it can be picked up for later record updates or deletes. + + + Records indexed with the alvis filter + have similar means to discover the internal Zebra ID. + + + + The recordIdOpaque string parameter + is an client-supplied, opaque record + identifier, which may be used under + insert, update and delete operations. The + client software is responsible for assigning these to + records. This identifier will + replace zebra's own automagic identifier generation with a unique + mapping from recordIdOpaque to the + Zebra internal recordIdNumber. + The opaque recordIdOpaque string + identifiers + are not visible in retrieval records, nor are + searchable, so the value of this parameter is + questionable. It serves mostly as a convenient mapping from + application domain string identifiers to Zebra internal ID's. + + + + + + + Extended services from yaz-client + We can now start a yaz-client admin session and create a database: @@ -1469,14 +1655,11 @@ where g = rset_count(terms[i]->rset) is the count of all documents in this speci from example/gils/records) and index it: update insert 1 esdd0006.grs + Z> update insert id1234 esdd0006.grs ]]> - The 3rd parameter - 1 here - - is the opaque record ID from Ext update. - It a record ID that we assign to the record - in question. If we do not - assign one, the usual rules for match apply (recordId: from zebra.cfg). + The 3rd parameter - id1234 here - + is the recordIdOpaque package field. Actually, we should have a way to specify "no opaque record id" for @@ -1498,10 +1681,11 @@ where g = rset_count(terms[i]->rset) is the count of all documents in this speci - Let's delete the beast: + Let's delete the beast, using the same + recordIdOpaque string parameter: update delete 1 + Z> update delete id1234 No last record (update ignored) Z> update delete 1 esdd0006.grs Got extended services response @@ -1530,8 +1714,14 @@ where g = rset_count(terms[i]->rset) is the count of all documents in this speci after each update session in order write your changes from the shadow to the life register space. + + + + + Extended services from yaz-php + - Extended services are also available from the YAZ client layer. An + Extended services are also available from the YAZ PHP client layer. An example of an YAZ-PHP extended service transaction is given here: rset) is the count of all documents in this speci echo "$error"; ]]> - The action parameter can be any of - recordInsert (will fail if the record already exists), - recordReplace (will fail if the record does not exist), - recordDelete (will fail if the record does not - exist), and - specialUpdate (will insert or update the record - as needed). - - - If a record is inserted - using the action recordInsert - one can specify the optional - recordIdOpaque parameter, which is a - client-supplied, opaque record identifier. This identifier will - replace zebra's own automagic identifier generation. - - - When using the action recordReplace or - recordDelete, one must specify the additional - recordIdNumber parameter, which must be an - existing Zebra internal system ID number. When retrieving existing - records, the ID number is returned in the field - /*/id:idzebra/localnumber in the namespace - xmlns:id="http://www.indexdata.dk/zebra/", - where it can be picked up for later record updates or deletes. - + + -- 1.7.10.4