Stefan Sperling <s...@elego.de> writes: > On Tue, Mar 15, 2011 at 10:26:15AM +0000, Philip Martin wrote: >> Branko Čibej <br...@e-reka.si> writes: >> >> > The restriction that you may not invoke a callback from within a sqlite >> > transaction remains. That's what the temporary results tables are for -- >> > they live outside transactions on the main wc-db. >> >> I don't understand the temporary table approach. Taking the >> temp__node_props_cache table as an example: it gets populated by a >> transaction and lives beyond that transaction. The table then gets >> queried by a second transaction and the callbacks are made while that >> second transaction is in progress. So callbacks are still being invoked >> from within a transaction. > > It works around the infinite loop problem that happens when the > callback inserts rows that end up being picked up by the proplist query. > Which is silly for this callback to do, but then again we somehow agreed > that the callbacks are free to do virtually anything. (I still think > putting newly documented restrictions on them now is fine and would make > our life easier... *shrug*).
I'm still confused. I thought the infinite loop problem affected the old multiple transaction code. If we simply ran a single transaction and made callbacks then that problem would not exist. We would have the same limitations that apply to the temporary table approach: the callback cannot write to the database because a transaction is in progress. >> As far as I can see using a temporary table has made the overall "read >> properties" operation into one that modifies the database, to create the >> temporary table. I guess that by the time the callbacks are made the >> database write-lock has been dropped, but there would have been no >> write-lock if the temporary table were not used. > > I think the temporary table gets put into a separate database file > (or memory, depending on the temp_store pragma or whatsitcalled). > If so, a read lock on the primary db should suffice, shouldn't it? Yes, by the time we invoke the callbacks we have a read-lock. If we simply ran a single transaction and made callbacks within the transaction then it would have the same effect. I don't see what the temporary table achieves. -- Philip
