On 2/21/13, Branko Čibej <[email protected]> wrote: > On 21.02.2013 22:00, Olemis Lang wrote: >> On 2/21/13, Branko Čibej <[email protected]> wrote: >>> On 20.02.2013 11:43, Jure Zitnik wrote: >>> >> [...] >>> Control of the location of temporary databases (hence, temporary tables) >>> is independent of the type of the main database. You can issue this >>> statement: >>> >>> PRAGMA temp_store = MEMORY; >>> >>> when you open the sqlite connection, this will override whatever >>> compile-time default your SQLite installation has and force the >>> temporary database to be in-memory. See: >>> >>> http://www.sqlite.org/pragma.html#pragma_temp_store >>> >> I wouldn't be against using this ... as long as it won't cause major >> trouble . > > That depends. This setting is per-connection, so theoretically you could > use it only during testing or database upgrade, and not during other > operations. >
That was exactly what I was trying to say ... «I wouldn't be against using this» and «this» = revert to using TEMP table in upgrade method + setting PRAGMA in TC's __init__ or setUp (depending on whether we'll use env stubs with SQLite only or also for other backends , we should check that too ;) ... ;) > It also helps if whatever is opening the connections cleans up after > itself and closes them after it's done, this is already done since the very time I moved calls to _setup_test_log into TC's setUp method , I also took these kinds of precautions `reset_db` et al . In general shoutdown cannot be invoked with in memory SQLite DB (btw possible for functional TCs ;) , etc , etc ... the only fact is that all cleanups happen in tearDown and fd(s) were opened in __init__ and setUp . So in principle , there was no chance to control this even if test code was correctly written . > or you're likely to get dangling > transactions (eventually) and heisenbugs that, of course, only show up > at a user's site and cannot be replicated locally. :) > In any case we shall take a look into this ... ;) -- Regards, Olemis.
