Fast full-text searching in Python (job for Whoosh?)

[Peter J. Holzer]

On 2023-03-08 00:12:04 -0500, Thomas Passin wrote:
> On 3/7/2023 7:33 AM, Dino wrote:
> > in fact it's a dilemma I am facing now. My back-end returns 10
> > entries (I am limiting to max 10 matches server side for reasons you
> > can imagine). As the user keeps typing, should I restrict the
> > existing result set based on the new information or re-issue a API
> > call to the server? Things get confusing pretty fast for the user.
> > You don't want too many cooks in kitchen, I guess.
> > Played a little bit with both approaches in my little application.
> > Re-requesting from the server seems to win hands down in my case.
> > I am sure that them google engineers reached spectacular levels of UI
> > finesse with stuff like this.
> 
> Subject of course to trying this out, I would be inclined to send a much
> larger list of responses to the client, and let the client reduce the number
> to be displayed.  The latency for sending a longer list will be smaller than
> establishing a new connection or even reusing an old one to send a new,
> short list of responses.

That depends very much on how long that list can become. If it's 200
matches - sure, send them all, even if the client will display only 10
of them. Probably even for 2000. But if you might get 20 million matches
you surely don't want to send them all to the client.

        hp

-- 
   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | hjp at hjp.at         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://mail.python.org/pipermail/python-list/attachments/20230308/76396f48/attachment.sig>