Session extension & attached databases

[ignatz]

let session = Session::new_with_name(&conn, "attached").unwrap();
session.attach::<&str>(None).unwrap();

can be used to create a session object for an attached databases. The recording of changesets works as expected. However, I haven't found a way to apply a changeset to an attached database. I had a quick look at ffi::sqlite3changeset_apply and didn't find a flavor with a database parameter. Am I missing something?

Just feels a bit asymmetric that one can record but not apply 🤷

[gwenn]

By default, the session feature is not documented on docs.rs but you can generate the doc locally:

cargo doc --open --no-deps --features 'session bundled'

rusqlite/src/session.rs

Lines 396 to 398 in 8ae9407

	/// An item passed to a conflict-handler by
	/// [`Connection::apply`](Connection::apply), or an item generated by
	/// [`ChangesetIter::next`](ChangesetIter::next).

and

rusqlite/src/session.rs

Lines 582 to 587 in 8ae9407

	/// Apply a changeset to a database
	pub fn apply<F, C>(&self, cs: &Changeset, filter: Option<F>, conflict: C) -> Result<()>
	where
	F: Fn(&str) -> bool + Send + 'static,
	C: Fn(ConflictType, ChangesetItem) -> ConflictAction + Send + 'static,
	{

[ignatz]

I read the code, I looked at the ffi bindings. Is the answer to my question in the docs and I missed it?

[gwenn]

I had a quick look at ffi::sqlite3changeset_apply and didn't find a flavor with a database parameter. Am I missing something?

vs
pub fn apply<F, C>(&self, cs: &Changeset, filter: Option, conflict: C) -> Result<()>

[ignatz]

I can apply to a connection. It will be applied to the "main" database. Curiously, it doesn't seem to fail when it should. But what I really want is to apply the inverse to another attached database. If I'm recording from "attached.table", I would like to apply the inverse to "attached.table" and not to "main.table". I'm probably not expressing myself very clearly. Happy to share some code, when I'm back at my machine. Either way thanks for your quick reply

…

On Mon, 26 May 2025, 19:24 gwenn, ***@***.***> wrote: I had a quick look at ffi::sqlite3changeset_apply and didn't find a flavor with a database parameter. Am I missing something? vs pub fn apply<F, C>(*&self*, cs: &Changeset, filter: Option, conflict: C) -> Result<()> — Reply to this email directly, view it on GitHub <#1702 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA3K4THTRSI6LW4W5PUF433ANE4ZAVCNFSM6AAAAAB5566OPCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGMRXGQ4DQOI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[gwenn]

I am not sure but I think you have to open a dedicated connection to the attached database:
https://sqlite.org/sessionintro.html

The session extension provide a mechanism for conviently recording changes to some or all of certain tables in an SQLite database, and packaging those changes into a "changeset" or "patchset" file that can later be used to apply the same set of changes to another database with the same schema and compatible starting data.

A single changeset may contain changes that apply to more than one database table. For each table that the changeset includes at least one change for, it also encodes the following data:
The name of the database table,

[ignatz]

Thanks for confirming. That was my impression as well when looking at the bidnings. I guess the referenced sqlite docs spell it out explicitly:

It feels asymmetric and worse, doesn't work for in-memory databases, since I cannot just re-open an existing in-memory database in a new connection :/

Thanks!

[gwenn]

You should be able to open several connections to the same in-memory database with the same URI (if you keep at least one connection opened all the time) like: file:mem1.db?mode=memory&cache=shared

[ignatz]

Asymmetry aside, that works for me. Awesome - thanks!

EDIT: just for prosperity. There are certainly limitations. E.g. opening a new connection will by-pass any hooks you may have installed, ... . Generally, it would be nice if apply would allow specifying the database but that's an ask for Sqlite and not rusqlite.