It would be useful to have dates for created and for edited on the articles. With the huge scope of the SQLite project, I have no idea whether this is historical, current, or upcoming.
Fantastic, looks like something I need! Some questions in case someone knows:
- is the source DB blocked in any way when this is running? E.g. is this like an ordinary read, or something different? I know WAL mode gives more concurrency but still writes are queued up in the wal file during a long read
- can this operate on a ~continuous basis? Or can I run it every few mins?
> is the source DB blocked in any way when this is running?
Doesn't sound like it: "If other processes change the content of ORIGIN while this command is running, those changes will be applied to ORIGIN, but they are not transferred to REPLICA"
Sounds like it uses the internal snapshot mechanism[0] and replicates that.
Why not both? They solve different problems, after all.
I'm currently using `litestream` for backups but I might add `sqlite3_rsync` as a point-in-time replica for things that benefit from "remote" sqlite access - easier than restoring a version from `litestream`, safer than copying it myself, and a lot easier than transporting changes over NATS / HTTP / whatnot.
12 comments
[ 3.0 ms ] story [ 33.4 ms ] threadIt would be useful to have dates for created and for edited on the articles. With the huge scope of the SQLite project, I have no idea whether this is historical, current, or upcoming.
https://github.com/sqlite/sqlite/commit/a9c8f7cf34545f410e94...
https://sqlite.org/news.html
- is the source DB blocked in any way when this is running? E.g. is this like an ordinary read, or something different? I know WAL mode gives more concurrency but still writes are queued up in the wal file during a long read
- can this operate on a ~continuous basis? Or can I run it every few mins?
Thanks!
Doesn't sound like it: "If other processes change the content of ORIGIN while this command is running, those changes will be applied to ORIGIN, but they are not transferred to REPLICA"
Sounds like it uses the internal snapshot mechanism[0] and replicates that.
[0] https://www.sqlite.org/c3ref/snapshot.html
[0] https://litestream.io/
I'm currently using `litestream` for backups but I might add `sqlite3_rsync` as a point-in-time replica for things that benefit from "remote" sqlite access - easier than restoring a version from `litestream`, safer than copying it myself, and a lot easier than transporting changes over NATS / HTTP / whatnot.