X-Git-Url: http://mj.ucw.cz/gitweb/?a=blobdiff_plain;f=lib%2Fperl%2FQuery.pm;h=9a8b168e79978047138394ffbd537829a5ef6fc0;hb=3cf2b0aaf15a2076c18de7e684703c175ed05d4e;hp=bb4c9c1da7c3179d29f2a4b5bb567a321898c921;hpb=a3ed0ceaec2cfe2ded48fa428f5144727d31de28;p=libucw.git diff --git a/lib/perl/Query.pm b/lib/perl/Query.pm index bb4c9c1d..9a8b168e 100644 --- a/lib/perl/Query.pm +++ b/lib/perl/Query.pm @@ -1,10 +1,91 @@ # Perl module for sending queries to Sherlock search servers and parsing answers # -# (c) 2002 Martin Mares +# (c) 2002--2003 Martin Mares # # This software may be freely distributed and used according to the terms # of the GNU Lesser General Public License. +=head1 NAME + +Sherlock::Query -- Communication with Sherlock Search Servers + +=head1 DESCRIPTION + +This perl library offers a simple interface for connecting to Sherlock +search servers, sending queries or control commands and parsing the +results. + +First of all, you have to use + + my $conn = new Sherlock::Query('server:port'); + +to create a new connection object (unconnected yet). Then you can call + + my $res = $conn->command('command'); + +to establish the connection, send a given command to the search server +and gather the results (see below) or, if you want to send a normal query, + + my $res = $conn->query('"simple" OR "query"'); + +which does the same as C<< $conn->command(...) >>, but it also parses the +results to a representation convenient for handling in Perl programs +(again, see below). + +Currently, you can use a single connection to send only a single command or query. + +=head1 RESULTS + +The I of the search server (i.e., the lines it has returned) is always +available as C<< $conn->{RAW} >> as a list of strings, each representing a single +line. + +Parsed results of queries are stored in a more complicated way, but before +explaining it, let's mention a couple of axioms: Any search server I +(header, footer, a single document of answer) is always stored as a hash keyed +by attribute names. Ordinary single-valued attributes are stored as strings, +multi-valued attributes as (references to) arrays of strings. When an object +contains sub-objects, they are stored as references to other hashes, possibly +encapsulated within a list if there can be multiple such objects. Most objects +have an extra attribute C containing the original description of the +object, a sub-list of C<< $conn->{RAW} >>. + +The parsed answer consists of three parts (please follow F to +get a better picture of what does the server answer): header C<< $conn->{HEADER} >> +(an object, as described above), footer C<< $conn->{FOOTER} >> (object) and document +cards C<< $conn->{CARDS} >> (a list of objects). + +The I
contains all the standard header attributes and also C<< $hdr->{D} >> +which is a list of sub-objects, each corresponding to a single database and +containing per-database attributes like C (word list). + +The I