This shows that passing the database into the Raft module is probably
not going to work, since the database could be opened in two ways -
directly at startup, and be completely restored from the log, or with
a combination of restoring from a snapshot, followed by the remaining
log entries. In both cases the database must be opened using the
requested DSN settings.
A detailed config object for controlling SQLite behaviour, is probably
best, and it should be passed to the Raft store on start up.
Finally, file-level copying of the SQLite file can only take place if
no transaction is in effect. This might be handled by the use of a
RWLock. The write-lock is taken during Execute() and Snapshot, but
the Read lock is taken during Query(). Unfortunately this may reduce
the concurrency of inserts and updates. Perhaps the Backup call on
the Go SQLite library might be better, but it might be slow.
This reverts commit f2de6cc26e, reversing
changes made to cdc6021ae7.
The change causes a panic when the server is started like so:
$GOPATH/bin/rqlite ~/node.1
db/db.go:14:1⚠️ dbName is unused
db/db.go:30:11⚠️ error return value not checked (os.Remove(dbPath))
db/db.go:63:18⚠️ error return value not checked (defer rows.Close())
db/db.go:15:⚠️ unused global variable dbName
Philip O Toole
Fernando Álvarez