Add support for online backup API about rusqlite HOT 13 CLOSED

It's not currently supported, but @gwenn opened a PR (#59) which adds support for it. I've been pretty swamped at work, but I'll try to get to that PR (and the other open ones) soon.

from rusqlite.

@jgallagher any movement on this?

from rusqlite.

The API provided by my PR may be to restrictive.
It's a simple transcription of the TCL API:
https://www.sqlite.org/tclsqlite.html#backup

from rusqlite.

@gwenn why is it considered restrictive?

from rusqlite.

• Destination database name,
• Number of pages copied,
• Error (SQLITE_BUSY, SQLITE_LOCKED) handling while stepping,

are hard-coded.

from rusqlite.

@gwenn @dashed I took a shot at implementing a more robust and Rust-y interface for online backup. Could you guys please take a look at #93 and see what you think? If you have actual programs that are using this or want to use it and you could give it a shot, that would be even better.

from rusqlite.

Maybe I am biased.
But I think that the main use case is "Backup the current ('main') database to a file".
So it seems wise to have a simple function that makes this main use case easy to do:

impl SqliteConnection {
    pub fn backup<P: AsRef<Path>>(&self, name: BackupName, dst_path: &P) -> SqliteResult<()> {
        let dst = try!(SqliteConnection::open(dst_path));
        let backup = try!(Backup::new_with_names(&src, name, &mut dst, BackupName::Main));
        backup.run_to_completion(100, Duration::from_millis(250), None)
    }
    // And may be restore...
}

from rusqlite.

If we did add it, we'd have to make a bunch of decisions that seem a little problematic:

• pagecount / sleep time (100/100 is used in the TCL and JDBC interfaces; the SQLite docs use 5/250 in their "how to do a backup" example)
• Should we fail after too many BUSYs? (TCL/JDBC include this for restore but not backup)
• Should we include a hook for a progress function? (TCL doesn't have this but JDBC does)

Given how short implementing these options would be, I lean toward letting clients decide how they want to do the backups. I could be convinced otherwise though if you feel strongly about it.

from rusqlite.

Another unrelated point:
At least, the following functions also take a database name ("main", "temp", ...) as argument:

• http://sqlite.org/c3ref/blob_open.html
• http://sqlite.org/c3ref/db_readonly.html
• http://sqlite.org/c3ref/table_column_metadata.html
• http://sqlite.org/c3ref/wal_checkpoint_v2.html

So BackupName may be too specific.

from rusqlite.

Thanks, renamed it to DatabaseName in 89b5875.

I'm still going back and forth on backup and restore. I'm leaning toward going ahead and putting them in with 100/100 and including an Optional progress function (like JDBC's) - I think you're right that most uses will want something simple, and they can always use the full backup mod if they want full control. So the signatures would be

impl SqliteConnection {
    pub fn backup<P: AsRef<Path>>(&self, name: DatabaseName, dst_path: &P, progress: Option<fn(backup::Progress)>) -> SqliteResult<()> { ... }
    pub fn restore<P: AsRef<Path>>(&mut self, name: DatabaseName, src_path: &P, progress: Option<fn(backup::Progress)>) -> SqliteResult<()> { ... }
}

What do you think?

from rusqlite.

LGTM

from rusqlite.

Implemented as of #93.

from rusqlite.

Sorry haven't responded sooner. But the new API looks much cleaner to use! 👍

from rusqlite.