On 16 Mar 2010, at 5:17pm, HLS wrote:

> Once approach is to queue any updates/deletes when the database is
> locked with a select request.  So when a fetch ends (like in the
> GetNextxxxx function), it will check to see for any pending updates
> and process them.
> Does that sound like a viable approach with SQLITE3?
> Hmmmmm, this would not address possible client code that can break
> from a loop before reaching the end of select query.

For the approach that involves queueing write commands, you do definitely need 
to know when a SELECT has finished with the database.  But SQLite depends on 
that anyway, and there's no reason why it shouldn't depend on correct usage of 
the API including sqlite3_finalize() .

I have one installation where it's okay for SELECT commands to return results 
which are slightly out of date, but new data becomes available at sparse and 
irregular intervals from many sources.  Consequently, this system delays write 
commands until there has been no access to the database for one minute (checked 
by touching a file whenever sqlite3_prepare() is done).  In this particular 
installation this makes perfect sense, because the patterns of reads and writes 
is well understood.  However, for some random installation for a random use of 
SQLite it would be disastrous.  You may be in a situation where you can develop 
a protocol which fits your particular use of SQL very well even though the 
solution would be useless for a more general use of SQLite.

sqlite-users mailing list

Reply via email to