Alejandro Martínez wrote:
Thanks Richard, that makes perfect sense.
Thanks Howard, but i don't know what you are talking about, so i will
google "copy-on-write".
See the papers and presentations here:
http://www.symas.com/mdb
Source code for SQLite is here:
http://gitorious.org/mdb
Thanks Richard, that makes perfect sense.
Thanks Howard, but i don't know what you are talking about, so i will
google "copy-on-write".
Григорий Григоренко, Interesting! I'll consider this approach if at some
point i'm able to go "scorched earth" and start this from scratch, but at
this point i
Hi,
CREATE TABLE rev(current); INSERT INTO rev VALUES(0);
CREATE TABLE data(..., revision);
Readers:
SELECT * FROM data JOIN rev ON revision = current WHERE ... ;
// or "SELECT current FROM rev" into var and passing it value in "SELECT * FROM
data WHERE revision=?"
Writer:
// insert new
Richard Hipp wrote:
On Wed, Nov 28, 2012 at 9:58 AM, Alejandro Martínez wrote:
And wouldn't PRAGMA read_uncommitted achieve the effect i was expecting? Or
does that cause other problems?
read_uncommitted only works if both the read and writer are in the same
process and
On Wed, Nov 28, 2012 at 9:58 AM, Alejandro Martínez wrote:
> And wouldn't PRAGMA read_uncommitted achieve the effect i was expecting? Or
> does that cause other problems?
>
read_uncommitted only works if both the read and writer are in the same
process and are using shared
And wouldn't PRAGMA read_uncommitted achieve the effect i was expecting? Or
does that cause other problems?
Reading "old" or inconsistent data would not be a problem for me. (as long
as it is not corrupted data).
On Wed, Nov 28, 2012 at 11:20 AM, Richard Hipp wrote:
> On Wed,
On Wed, Nov 28, 2012 at 7:09 AM, Alejandro Martínez wrote:
> Ok, i will probably do that. Thank you.
>
> But i'd like to know. Why doesn't this work without wal? A read only
> operation shouldn't block, right?
>
If you are not running WAL, then the database is updated
Ok, i will probably do that. Thank you.
But i'd like to know. Why doesn't this work without wal? A read only
operation shouldn't block, right?
And regarding the commit failing, does that need a busy timeout handler
too? From documentation i though it would just wait until all readers are
done
On Wed, Nov 28, 2012 at 6:56 AM, Alejandro Martínez wrote:
> Is that the only way?
>
> When i had done that in the past, the wal file grew constantly and i am
> afraid it could fill the hard disk.
>
> That could happen if say... one of the reading processes doesn't
> properly
Is that the only way?
When i had done that in the past, the wal file grew constantly and i am
afraid it could fill the hard disk.
That could happen if say... one of the reading processes doesn't
properly sqlite3_reset a prepared statement after stepping it. right?
Thank you for your quick
On Wed, Nov 28, 2012 at 6:47 AM, Alejandro Martínez wrote:
> I have one process that each 30 minutes refills several tables in this
> manner:
>
> sqlite3_open_v2(CACHEDB_PATH, _conn, SQLITE_OPEN_CREATE |
> SQLITE_OPEN_READWRITE, NULL)
>
> - For each table:
>
> begin deferred
Extra info.
Its running on this:
SunOS 5.10 Generic_144488-11 sun4u sparc SUNW,Sun-Fire-V490
On Wed, Nov 28, 2012 at 9:47 AM, Alejandro Martínez wrote:
> I have one process that each 30 minutes refills several tables in this
> manner:
>
> sqlite3_open_v2(CACHEDB_PATH,
I have one process that each 30 minutes refills several tables in this
manner:
sqlite3_open_v2(CACHEDB_PATH, _conn, SQLITE_OPEN_CREATE |
SQLITE_OPEN_READWRITE, NULL)
- For each table:
begin deferred transaction; delete from [table];
insert into table ...
insert into table ...
insert into table
13 matches
Mail list logo