On Wed, 4 Jan 2006, Steve Lhomme wrote:
>[EMAIL PROTECTED] wrote:
>> Peter Bierman <[EMAIL PROTECTED]> wrote:
>>
>>>Related to a project I'm working on, it would be useful for me to be
>>>able to open a database file via passing an already open file
>>>descriptor to the sqlite open() call. sqlite3_openfd().
>>>
>>
>> That is not possible. SQLite needs to know the name of
>> the file so that it can create an appropriate rollback
>> journal in order to do atomic commits.
>
>But it's totally possible to do that in memory too. I would just like to
>avoid using a RamDisk. As I will probably need that feature I might
>commit it and send a patch here.
Rollback in memory? If the machine crashes or loses power half way though,
you lose rollback information.
SQLite can already use a memory database, including ACID transactions. If
all you're after is transient database functionality, this is all you
need.
If you want a fast read-only database from a disk file, just use the disk
file and let the OS and SQLite cache keep things fast. You don't need a
rollback journal for read-only operations.
Suggestion:
Write a method on top of SQLite that, given 2 SQLite database handles,
will sync the two databases:
int sqlite3_syncdb( sqlite3 * from, sqlite * to );
The symantics would be to transfer the schema and data from the 'from'
database to the 'to' database. You could use the SQLite shell .dump
command as a template on how to generate the commands required for
syncing.
When starting your program, you sync from your disk database to your empty
memory database. When exiting your program, you sync from your memory
database to your disk database. You then have the quick memory and
ACID based transactions during the life of your program, at the cost of
slow startup and shutdown while the data is synced (and the potential for
lost data if the application dies for whatever reason without syncing
back.)
>
>Steve
>
Christian
--
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST MS ATTACHMENTS
/ \
