X-Git-Url: http://git.indexdata.com/?p=irspy-moved-to-github.git;a=blobdiff_plain;f=lib%2FZOOM%2FPod.pm;h=dd6e14c86da6a9e84734081f72211d2221f00cef;hp=9ddbd516295685e00229e190c076a5f63fb91c3d;hb=50603f0ba0ffb480007d139143ef74cdfb69f3a6;hpb=e973295d211061e778b542af139d8d9e31c689bb diff --git a/lib/ZOOM/Pod.pm b/lib/ZOOM/Pod.pm index 9ddbd51..dd6e14c 100644 --- a/lib/ZOOM/Pod.pm +++ b/lib/ZOOM/Pod.pm @@ -1,4 +1,4 @@ -# $Id: Pod.pm,v 1.6 2006-05-10 16:44:57 mike Exp $ +# $Id: Pod.pm,v 1.10 2006-05-12 13:31:00 mike Exp $ package ZOOM::Pod; @@ -132,12 +132,66 @@ sub option { =head2 callback() -I<###> + $pod->callback(ZOOM::Event::RECV_SEARCH, \&completed_search); + $pod->callback("exception", sub { print "never mind: $@\n"; return 0 } ); + +Registers a callback to be invoked by the pod when an event happens. +Callback functions are invoked by C (q.v.). + +When registering a callback, the first argument is an event-code - one +of those defined in the C enumeration - and the second is +a function reference, or equivalently an inline code-fragment. It is +acceptable to nominate the same function as the callback for multiple +events, by multiple invocations of C. + +When an event occurs during the execution of C, the relevant +callback function is called with four arguments: the connection that the +event happened on; a state hash-reference associated with the +connection; the result-set associated with the connection; and the +event-type (so that a single function that handles events of multiple +types can switch on the code where necessary). The callback function +can handle the event as it wishes, finishing up by returning an +integer. If this is zero, then C continues as normal; if it +is anything else, then that value is immediately returned from +C. + +So a simple event-handler might look like this: + + sub got_event { + ($conn, $state, $rs, $event) = @_; + print "event $event on connection ", $conn->option("host"), "\n"; + print "Found ", $rs->size(), " records\n" + if $event == ZOOM::Event::RECV_SEARCH; + return 0; + } -It is passed the connection that the event happened on, a state -hash-reference associated with the connection, the connection's -result-set and the event-type (so that a single function can handle -events of multiple types, switching on the code where necessary). +In addition to the event-type callbacks discussed above, there is a +special callback, C<"exception">, which is invoked if an exception +occurs. This will nearly always be a ZOOM error, but this can be +tested using C<$exception-Eisa("ZOOM::Exception")>. This callback is +invoked with the same arguments as described above, except that +instead of the event-type, the fourth argument is a copy of the +exception, C<$@>. Exception-handling callbacks may of course re-throw +the exception using C. + +So a simple error-handler might look like this: + + sub got_error { + ($conn, $state, $rs, $exception) = @_; + if ($exception->isa("ZOOM::Exception")) { + print "Caught error $exception - continuing"; + return 0; + } + die $exception; + } + +The C<$state> argument is a reference to an initially empty hash, +which the application can use as it sees fit, to store its own +connection-relation information. For example, an application might +use C<$state-E{last}> to keep a record of which was the last record +retrieved from the associated connection. The pod module itself does +not use the state hash at all, and applications are also welcome to +ignore it if they do not need it. =cut @@ -154,12 +208,23 @@ sub callback { =head2 search_pqf() -I<###> + $pod->search_pqf("@attr 1=1003 wedel"); + +Submits the specified query to each of the connections in a pod, +delegating to the same-named method of the C class +and storing each result in a result-set object associated with the +connection that generated it. Returns no value: success or failure +must subsequently be detected by inspecting the events and exceptions +generated by Cing on the pod. B An important simplifying assumption is that each connection can only -have one search active on it at a time - this allows the pod to -maintain a one-to-one mapping between connections and result-sets. +have one search active on it at a time: this allows the pod to +maintain the one-to-one mapping between connections and result-sets. +Submitting a new search on a connection before the old one has +completed will result in a total failure in the nature of causality, +and the spontaneous existence-failure of the universe. Do not do +this. =cut @@ -174,7 +239,23 @@ sub search_pqf { =head2 wait() -I<###> + $err = $pod->wait(); + die "$pod->wait() failed with error $err" if $err; + +Waits for events on the connections that make up the pod, usually +continuing until there are no more events left and then returning +zero. Whenever an event occurs, a callback function is dispatched as +described above; if +that function returns a non-zero value, then C terminates +immediately, whether or not any events remain, and returns that value. + +If an error occurs on one of the connection in the pod, then it is +normally thrown as a C. If, however, there is a +special C<"exception"> callback registered, then the exception object +is passed to this instead. As usual, the return value of the callback +indicates whether C should continue (return-value 0) or return +immediately (any other value). Exception-handling callbacks may of +course re-throw the exception. =cut @@ -186,7 +267,7 @@ sub wait { my $conn = $this->{conn}->[$i-1]; my $ev = $conn->last_event(); my $evstr = ZOOM::event_str($ev); - ZOOM::Log::log("pod", "connection ", $i-1, ": $evstr"); + ZOOM::Log::log("pod", "connection ", $i-1, ": event $ev ($evstr)"); eval { $conn->_check(); @@ -205,7 +286,7 @@ sub wait { $this->{rs}->[$i-1], $ev); last if $res != 0; } else { - ZOOM::Log::log("pod_unhandled", "unhandled event $ev ($evstr)"); + ZOOM::Log::log("pod_unhandled", "connection ", $i-1, ": unhandled event $ev ($evstr)"); } } @@ -213,6 +294,28 @@ sub wait { } +=head1 LOGGING + +This module generates logging messages using C, +which in turn relies on the YAZ logging facilities. It uses two +logging levels: + +=over 4 + +=item pod + +Logs all events. + +=item pod_unhandled + +Logs unhandled events, i.e. events of types for which no callback has +been registered. + +=back + +These logging levels can be turned on by setting the C +environment variable to C. + =head1 SEE ALSO The underlying