Hello all,
I have two slightly related questions regarding sqlite database handles.
First, I'm developing a system that opens thousands of different
sqlite databases at a variety of times, some database handles more
often than others, but never the same one multiple times concurrently,
though som
ement will definitively, actually hit disk, whereas
filtering by SELECT seemed unclear to me as to whether it would quite
cover or catch everything.
If that is truly the best way, then that's fine I guess.
-JT
On Thu, Jul 15, 2010 at 12:25 PM, Simon Slavin wrote:
>
> On 15 Jul 2010, at
t 12:41 PM, Jim Morris wrote:
> You also need to watch for multiple command separated via ';'
>
> On 7/15/2010 11:36 AM, JT Olds wrote:
>> I considered that also, but I wasn't sure about whether or not that
>> guaranteed no disk writes (maybe some sort of fu
> Unsafe. Using the authorizer callback instead to figure out if a
> statement may write the database is a better way:
>
> http://www.sqlite.org/c3ref/c_alter_table.html
> http://www.sqlite.org/c3ref/set_authorizer.html
Beautiful Dan, thank you. That problem I think has been nailed.
Any ideas
I have a large deployment of thousands of SQLite databases accessed
from the same multi-threaded process, and up until recently, I didn't
even consider thread safety, because
1) I only ever talk to a SQLite database connection from one thread at
a time, and
2) I am dumb.
I do maintain SQLite data
On this note, how does one figure out if your system does support
atomic writes (or other FS things, like safe appends)?
Is there an easy way to have SQLite tell you what it finds out?
Alternatively (for my current use case), does Ext3 on 2.6 Linux
support atomic writes or safe appends?
On Mon,
6 matches
Mail list logo