Simple search API proposal, take 2

[Magnus Bergman]

On Fri, 12 Jan 2007 08:41:10 +0100
Jean-Francois Dockes <jean-francois.dockes at wanadoo.fr> wrote:

> - CountHits() / GetHitproperties() racy-ness: It is up to the backend
> to maintain consistency inside a single opened query, the current
> interface allows it (unlike the previous one using the query string
> as a bad query_handle).
> 
>   Ideally the Query() call would open some kind of database snapshot
> which would be preserved as long as the query_handle is valid. This
> may be feasible or not with the current backends, which are expected
> to just "do their best", which the current draft does not prevent.
> Aren't things such as CountHits() usually considered to only return
> estimates anyway ?

For the simple API I expect result to be a snapshot (in the same way as
the result from an SQL-query is). There might be problems it items in
the result suddenly disappear or change, but I guess there isn't much
that can be done about it if we also want to keep the API simple.


> - GetHitProperties result list as map or sequence: as Fabrice wrote,
> the object identifiers are not useful. The results are requested as
> slices from of an ordered list (offset/limit), and should be returned
> as a simple sequence or array of (propertyName=>propertyValue) maps. 
> 
>   Magnus' initially proposed the response to be:
>    "A map mapping each hit (sequence number) to a map of
> property-list of values pairs." 
> 
>   I think that the sequence number can be kept implicit:
> 
>     Query (in s query_string, out i query_handle)
>     GetHitProperties ( in s query_handle, in i offset, in i limit, 
>                        in as properties, out (sequence of maps)
> response )

What you call "offset" is exactly what I meant by "sequence number", if
I didn't misunderstand something. The alternative (really keeping it
implicit) would be to completely leave it out and just return the bunch
of hits (much like how read(2) works. But that would also require a
function similar to lseek(2), so I guess it wouldn't be simpler anyway.