On 4/11/17, Reid Thompson <reid.thomp...@ateb.com> wrote: > > I/and the original implementer, am/were more familiar with PostgreSQL's > MVCC. So I think the issue was the assumption that the query being > stepped through would only ever see the rows as they were at the start > of the query and would walk through them from first to last. >
That is true, as long as the query and the workers are all using separate database connections. Trouble only arises when the query is run partially - not to completion - and then the table being queried is updated *on the same database connection*. Changes implemented on separate database connections are isolated and will not change the result of the original query. The problem scenario is impossible on PostgreSQL or any other client-server database because the client/server databases run the whole query all the way to the end before returning the results to you. It has nothing to do with MVCC. You can emulate the PostgreSQL behavior by: (1) Saving the query results in a TEMP table and then querying the TEMP table separately and running the workers based on the TEMP table. (2) Use the sqlite3_get_table() (or a similar wrapper of your own concoction) to load all query results into memory prior to starting the UPDATEs. -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
