On 2/22/13, Branko Čibej <[email protected]> wrote: > On 22.02.2013 10:06, Olemis Lang wrote: >> On 2/22/13, Olemis Lang <[email protected]> wrote: >>> 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: >> [...] >>>> 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 ;) ... >>> ;) >>> >> I forgot ... the only drawbacks I notice up to this point is the >> interaction with SQLITE_TEMP_STORE . If that is resolved at >> compilation time , after analyzing interactions table it seems to me >> that such approach might cause some headaches in practice . > > SQLITE_TEMP_STORE is the compile-time default. The pragma directive > overrides it in the sense that whatever value the compile-time symbol > has, you can always get in-memory temp store via the pragma. That's > quite clear from the interactions table, although it took me more than a > minute to see it when I first read it. :) >
jftr 0 + any => file 3 + any => memory so I guess with SQLITE_TEMP_STORE = 0 this would be impossible ? -- Regards, Olemis.
