Branko Čibej <brane_at_e-reka.si> writes:
> On 15.03.2011 15:34, Philip Martin wrote:
>> So with the temporary table approach the callback really has to use a
>> separate database connection to read/write the database from within the
>> callback.
>>
>> However I think that is also the case if we were to avoid the table and
>> simply lock the main database; if just one connection was reused it
>> might be attempt to reuse an SQLite statement.
>
> There's a trick we could use if that's a problem, namely: instead of
> simply creating temporary tables by using the connection's default temp
> database; create another temp *database* per query. It's anonymous, so
> only the code that holds its handle knows about it, and there's no way
> for the callback to access it.
>
> This would require a bit more code, however, the concept is a reusable
> pattern (and the code for the temp database handling would be reusable,
> too.)
Sounds plausible.
Is it valid for an application to call proplist and then in the callback
call proplist again, say on a different part of the working copy? To
support it I think we need to avoid using a fixed name for the temporary
database, perhaps we could use a sequence number in the database
connection structure?
I thought we would have this problem with the name of the temporary
table, but we get a database locked error first.
--
Philip
Received on 2011-03-15 21:01:55 CET