X-Git-Url: http://git.indexdata.com/?a=blobdiff_plain;f=doc%2Fadministration.xml;h=829ef7591505428863477952c443e459617edb76;hb=656a766f96dd92939c3604a7bf88f2355d040fc8;hp=0048634eea39604a8b8428a76f04ebee52f9e62b;hpb=95bb55fadc3ff69e78e6a61b2096f1326979424b;p=idzebra-moved-to-github.git diff --git a/doc/administration.xml b/doc/administration.xml index 0048634..829ef75 100644 --- a/doc/administration.xml +++ b/doc/administration.xml @@ -1,5 +1,5 @@ - + Administrating Zebra - @@ -1331,6 +1378,7 @@ where g = rset_count(terms[i]->rset) is the count of all documents in this speci mitaylor2microsoft.com --> + Dynamically ranking CQL queries @@ -1435,26 +1483,226 @@ where g = rset_count(terms[i]->rset) is the count of all documents in this speci Extended Services: Remote Insert, Update and Delete + + + Extended services are only supported when accessing the Zebra + server using the Z39.50 + protocol. The SRU protocol does + not support extended services. + + + The extended services are not enabled by default in zebra - due to the - fact that they modify the system. - In order to allow anybody to update, use - - perm.anonymous: rw - + fact that they modify the system. Zebra can be configured + to allow anybody to + search, and to allow only updates for a particular admin user in the main zebra configuration file zebra.cfg. - Or, even better, allow only updates for a particular admin user. For - user admin, you could use: + For user admin, you could use: + perm.anonymous: r perm.admin: rw passwd: passwordfile - And in passwordfile, specify users and - passwords as colon seperated strings: + And in the password file + passwordfile, you have to specify users and + encrypted passwords as colon separated strings. + Use a tool like htpasswd + to maintain the encrypted passwords. admin:secret - + + It is essential to configure Zebra to store records internally, + and to support + modifications and deletion of records: + + storeData: 1 + storeKeys: 1 + + The general record type should be set to any record filter which + is able to parse XML records, you may use any of the two + declarations (but not both simultaneously!) + + recordType: grs.xml + # recordType: alvis.filter_alvis_config.xml + + To enable transaction safe shadow indexing, + which is extra important for this kind of operation, set + + shadow: directoryname: size (e.g. 1000M) + + See for additional information on + these configuration options. + + + + It is not possible to carry information about record types or + similar to Zebra when using extended services, due to + limitations of the Z39.50 + protocol. Therefore, indexing filters can not be chosen on a + per-record basis. One and only one general XML indexing filter + must be defined. + + + + + + + + Extended services in the Z39.50 protocol + + + The Z39.50 standard allows + 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 + + + + Parameter + Value + Notes + + + + + type + 'update' + Must be set to trigger extended services + + + action + string + + Extended service action type with + one of four possible values: recordInsert, + recordReplace, + recordDelete, + and specialUpdate + + + + record + XML string + An XML formatted string containing the record + + + syntax + 'xml' + Only XML record syntax is supported + + + recordIdOpaque + string + + Optional client-supplied, opaque record + identifier used under insert operations. + + + + recordIdNumber + positive number + Zebra's internal system number, + not allowed for recordInsert or + specialUpdate actions which result in fresh + record inserts. + + + + databaseName + database 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, record deletion is not possible). + + + During all actions, 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. + See . + + + + Setting of the recordIdNumber parameter, + which must be an existing Zebra internal system ID number, is not + allowed during any recordInsert or + specialUpdate action resulting in fresh record + inserts. + + + + 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. + + + + A new element set for retrieval of internal record + data has been added, which can be used to access minimal records + containing only the recordIdNumber Zebra + internal ID, or the recordIdOpaque string + identifier. This works for any indexing filter used. + See . + + + + 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: @@ -1468,14 +1716,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 @@ -1497,10 +1742,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 @@ -1529,8 +1775,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. - - - - - - YAZ Frontend Virtual Hosts - - zebrasrv uses the YAZ server frontend and does - support multiple virtual servers behind multiple listening sockets. - &zebrasrv-virtual; - - - Section "Virtual Hosts" in the YAZ manual. - http://www.indexdata.dk/yaz/doc/server.vhosts.tkl - - - - - - Server Side CQL to PQF Query Translation - - Using the - <cql2rpn>l2rpn.txt</cql2rpn> - YAZ Frontend Virtual - Hosts option, one can configure - the YAZ Frontend CQL-to-PQF - converter, specifying the interpretation of various - CQL - indexes, relations, etc. in terms of Type-1 query attributes. - - - - For example, using server-side CQL-to-PQF conversion, one might - query a zebra server like this: - - querytype cql - Z> find text=(plant and soil) - ]]> - - and - if properly configured - even static relevance ranking can - be performed using CQL query syntax: - - find text = /relevant (plant and soil) - ]]> - - - - - By the way, the same configuration can be used to - search using client-side CQL-to-PQF conversion: - (the only difference is querytype cql2rpn - instead of - querytype cql, and the call specifying a local - conversion file) - - querytype cql2rpn - Z> find text=(plant and soil) - ]]> - - - - - Exhaustive information can be found in the - Section "Specification of CQL to RPN mappings" in the YAZ manual. - - http://www.indexdata.dk/yaz/doc/tools.tkl#tools.cql.map, - and shall therefore not be repeated here. - - + - -