----- Original Message -----
From: "Simon Slavin" <slav...@bigfraud.org>
To: <phi...@blastbay.com>; "General Discussion of SQLite Database"
<sqlite-users@sqlite.org>
Sent: Thursday, June 06, 2013 10:51 AM
Subject: Re: [sqlite] Serialize an in-memory database
On 6 Jun 2013, at 9:01am, Philip Bennefall <phi...@blastbay.com> wrote:
Since I don't believe that Windows for example has tmpfs (seems to be a
Unix thing), would the idea of constructing a vfs that just reads and
writes a huge memory block be doable?
Doable ? Yes. Use the code from one of the file-based VFSes and replace
all the 'read/write to file offset N" with 'read/write to memory offset N',
then sort out locking and a few other problems. Tedious and annoying to do
but doable if you write C.
Of advantage to many users ? I don't know. I don't see what the advantage
of doing this is over SQLite's standard ways of storing data in memory or in
a file. Who would use this ?
Also, I have a question. How big do you expect to make that block of memory
you grab when someone creates a new database ? One of the advantages of SQL
databases is that they grow as you get more data. You can't do this if
you're going to pre-grab a continuous block of memory. Do you expect to use
the C function realloc() a lot ?
Simon.
Hi Simon,
For my own part, I would usually have a database that is no more than a few
megabyte in size. A generic solution would be a lot harder than the one I am
considering for my own project, where I can cut corners due to the fact that
I know the size of my data at least roughly. What I want to achieve is to
serialize the data in such a way so that I can do other processing on it
before I render it to disk, such as custom compression and/or other things.
I am aware that there is an SqLite add-on to do this, but aside from the
fact that I cannot afford it I don't need to do this processing on the fly
either. I just want to take an in-memory database and put it in a compressed
and possibly encrypted file on disk in the end, without having to use a
temporary file as an intermediary.
I write C, so would have no trouble modifying one of the existing vfs
example implementations. Correct me if I am wrong, but do I really need to
do any kind of locking if I am not working with disk files? I am not working
with shared cache, either. I would have one database connection that would
only be accessed from one thread.
Kind regards,
Philip Bennefall
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
