RE: Sort criteria in Search Request

You don't want to execute the same SQL request twice.
Here is a simple solution, maybe it helps:

The server does an UNLOAD of the SQL search to a file that includes the name
of the ResultSet.
Whenever the server receives a Sort request on that ResultSet it uses the
file on disk.

By the way, you will have the same problem with the Present, I guess? So
this is a solution for Present, too...

Pieter van Lierop
Geac

> -----Original Message-----
> From: Robert Sanderson [mailto:azaroth@liverpool.ac.uk]
> Sent: dimanche 16 septembre 2001 14:47
> To: Ian Ibbotson
> Cc: ZIG
> Subject: Re: Sort criteria in Search Request
> 
> 
> 
> > instructions are bundled with the search criteria. As I 
> said at the time, I
> > suspect this comes from a long tradition of SQL where the 
> order by is an
> > integral part of the whole statment.
> 
> Right. But in Z39.50, it isn't explicit. Equally, you can't (as far as
> I'm aware) do something like:
> 
> search for X and scan the results by Y.
> 
> (compared to 'search for X and sort the results by Y')
> (eg:  'Search for books written by Tolkien, and browse their titles'
>  vs:  'Search for books written by Tolkien, and sort based on 
> their titles')
> 
> > > Could someone please explain the actual point of doing 
> this as opposed to
> > > just sending multiple requests as per the status quo?
> 
> > The real need for sort to be close to search-request is, as 
> the doc says, for
> > targets that need to be able to optimise the way they work. 
> I have a few SQL
> > backends, and it's really inconvienient to execute what can 
> be a heavy SQL
> > statement, only to have to immediately re-evaluate it 
> because a sort-request
> > has just come in and now we need to tag some order by 
> clause on the end.
> 
> So the point is just to make it easier for using SQL as a 
> backend then?
> 
> I don't have a great problem with doing this sort of thing, 
> but it seems
> to be getting away from what makes Z a good protocol for IR. 
> See also ZNG.
> Like Unix, you have small units that are put together in 
> various ways to
> get to the results you want, rather than the Microsoft one 
> thing-does-all
> approach.
> 
> On the other hand, look at Microsoft for what happens when 
> you 'extend' a
> protocol to make it more integrated with currently existing 
> applications.
> 
> Our (generic) Z client makes use of Explain. It's -extremely- 
> inconvenient
> that this simply isn't implemented at all in most servers, which means
> that most of the time we need to try to search -all- of the 
> possible USE
> attributes for supported indexes. With the (very good) 
> proposed Bib2, as I
> understand it, even this won't really be a feasable approach to
> discovering how its possible to get records from the target 
> as the index
> types are qualified semantically rather than having a separate set of
> attributes.
> 
> A lot of targets, according to their Supported Requests info 
> in Init don't
> support sort. And a lot of the ones that claim it, don't in 
> truth. Things
> like encapsulating sort in search tends to beg the questions 
> of is sort
> supported at all, and being able to find out that it is with 
> reliability.
> 
> Rob
> -- 
>       ,'/:.          Rob Sanderson (azaroth@liverpool.ac.uk)
>     ,'-/::::.        http://www.o-r-g.org/~azaroth/
>   ,'--/::(@)::.      Special Collections and Archives, extension 3142
> ,'---/::::::::::.    Syrinnia:  telnet:  syrinnia.o-r-g.org 7777
> ____/:::::::::::::.                WWW:  
> http://syrinnia.o-r-g.org:8000/
> I L L U M I N A T I
>

Received on Monday, 17 September 2001 03:26:21 UTC