On 2007-06-28 16:32, Dirk Meyer wrote:
> I need that in kaa.beacon.db. The reason is directory sort. A listdir
> can block and stuff like that (and a sorted result is much faster). So
> the server needs to be aware that what can block. kaa.db itself should
> not change.
If a kaa.db query could block for too long, it should yield. This
change _should_ be added to kaa.db. kaa.db performs quite a few
subqueries for any given query (especially during a keyword query) so it
can yield after any one of these and pass back whatever results it
managed to find.
If you need the whole result set (because it needs to be sorted, or for
whatever reason) that's fine. But not all queries need that.
> We could add support to the _client_ side that an artist query returns
> only x items at first, but that has nothing to do with the server and
> I'm only hacking on the server right now. IMHO the server should
> always get everything, otherwise it can not monitor changes.
I don't think you can implement it properly without support from the
server and support from kaa.db. For an async query:
1. Client makes request to server, say a keyword search.
2. Server does kaa.db query, which grabs first N rows and returns
InProgress.
3. Server passes the rows from kaa.db query back to client and
returns InProgress
4. Return to #2 on next mainloop step.
Implementing 'return only x items at first' in _only_ the client is
pointless, because the both beacon server and the underlying kaa.db
query would need to fetch all rows up front anyway. It obviates the point.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Freevo-cvslog mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freevo-cvslog
