views:

1160

answers:

3

In an application which embeds SQLite3 and uses an in-memory database, is it possible to replicate the database between two running instances of the application? I could do this by hand with a homebrew protocol duplicating all my DB accesses, but it seems like something that should be done inside the DB layer.

+2  A: 

Brute force approach: Send it the ".dump" command to create a text representation of the data. Read that data in into the second database. Not sure you can use that.

If you need a fine grained update (sending a copy of each upto the other copy), have a look at sqlite3_update_hook

But how do you plan to handle errors? For example, what happens when the copy of the DB in app2 can't make an update for some reason?

To solve this, move the database to a server process and have the two apps talk to it.

Aaron Digulla
Okay, so sqlite3_update_hook would be my starting point for layering that on at a row-by-row level. That's very helpful, thank you.In response to the other points, I avoid things which cannot be inserted by certain magic properties of the application. The desire for two separate instances rather than a central DB is driven by a robustness-by-distribution requirement, and sqlite is driven by a system resource limit.
kdt
Okay. Just make sure both copies run out of memory/disk space at the same time, etc.
Aaron Digulla
A: 

No it doesn't because the project's scope is being a simple in-process database. But because the database is just a single file, you could write your own replication script based on plain file copy operations, rsync or something similar.

If you really want a SQLite based client/server type of RDBMS, you could take a look at SQLiteDBMS.

Taneli Waltari
A: 

If you want replication in an in-memory database you need to look at berkeley DB (BDB). However the data model for BDB is string-string dictionary, so you loose the flexibility of SQL. plus it has a three clause license, so if your project is commercial you need to get licenses.

Hassan Syed