simple search api (was Re: mimetype standardisation by testsets)

[Jean-Francois Dockes]

"James \"Doc\" Livingston" writes:
 > On Thu, 2006-12-21 at 19:07 +0100, Jean-Francois Dockes wrote:
 > > About 2), URI *is* an appropriate handle, and probably the best as long as
 > > we can't guarantee the stability of the result set (that is: *if* we need
 > > separate Query() and GetSnippets() calls, *then* the URI is probably the
 > > best identifier to ensure consistency).
 > 
 > What if the URI of a given item can change? I'm think in particular of
 > the backends which handle "file got moved" in ways other the simple
 > "remove old and add new" method.
 > 
 > If you had to retrieve the URI as a property rather than it being a
 > unique identifier there would still obviously be some issues for things
 > that are using the simple non-live interface, but potentially having
 > stale data is what you get from using a non-live query.
 > 
 > Using an old URI as the unique identifier to retrieve other data (like
 > snippets or something) could lead to some  odd situations.

Oops, yes, you're right the URI can change too. 

Lacking stable item identifiers, the only solution I can see is to have the
initial query create and return a unique query identifier.

We would then rely on the database/index manager to ensure that all
activity related to this query identifier is either consistent or resulting
in errors.

The query string can't be used as a query identifier, except if we strictly
renounce relating data from different calls. Well, at least we now know why
it didn't look right :)

J.F. Dockes