[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: should one single search be able to encompass several databases?

On Thu, Jul 19, 2001 at 12:13:09PM -0700, Kurt D. Zeilenga wrote:
> At 11:25 AM 7/19/2001, Howard Chu wrote:

> >There's an issue that I haven't quite resolved in my mind: when you chain
> >multiple backends, and one of them has an error and is unable to fulfill a
> >search request, but the others are able to provide results, what kind of
> >error indication do you send back to the client?

> Depends on whether the error occurred during finding or during searching.
> If the error occurred during the finding of the base, then that error
> needs to be reported.  If the error occurred during searching, it's generally
> not reported UNLESS the searching cannot be continued (timeLimit, sizeLimit,
> busy, other, ...).

That sounds odd. ISTM you wouldn't chain backends for redundancy, you'd
chain them because they had different data. So if you had reason to believe
that one of the backends might have contained records you were seeking, and
that backend had a failure, the search should immediately return an error. 

Suppose somebody rips your phone book in half, and shreds the last part. 
Another person asks you for all the individuals who live on Main Street. Do 
you give them what you found in the first half and *not* report that the 
directory was half decimated? That just sounds wrong.

Should you return results found in the backend whose searches completed OK?
What does the protocol spec say? Can you return both data and indication of
failure? If so, then return data and indication of failure. (Better to say,
"Here are the folks on Main Street from the first half of the phone book,
which by the way was damaged." than "Sorry, half the book is gone. I can't
give you a conclusive data set, so I refuse to give you anything.") If not
discard the found results and return indication of failure, because
following the spec is more important than being helpful. :-)

Obviously it would be advantageous to have a system smart enough to know 
what subtrees each backend had data for, so you wouldn't include any 
backends in a query for which you knew that backend would have no relevant data.