On Tue, Mar 15, 2011 at 10:26:15AM +0000, Philip Martin wrote:
> Branko Čibej <brane_at_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*).
> 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?
Received on 2011-03-15 13:02:58 CET