Skip to content

ntx-builder: move to sqlite framework#2353

Open
SantiagoPittella wants to merge 1 commit into
nextfrom
migrate-ntx-builder-off-diesel
Open

ntx-builder: move to sqlite framework#2353
SantiagoPittella wants to merge 1 commit into
nextfrom
migrate-ntx-builder-off-diesel

Conversation

@SantiagoPittella

Copy link
Copy Markdown
Collaborator

Summary

Migrates the ntx-builder database layer off Diesel and onto the shared miden-node-db SQLite framework.

Why:

  • Removes the last Diesel dependency and its schema/codegen tooling from the ntx-builder.
  • Unifies persistence on one connection-pool + transaction model across the node.

How:

  • Replaces the Diesel query modules with plain query functions over ReadTx/WriteTx and hand-written SQL in db/sql/.
  • Drops the pinned "loop connection"; writes now serialize through the framework's single writer connection, reads use the shared reader pool.
  • On-disk layout is unchanged (same to_bytes()/read_from_bytes() codec, same 001_initial.sql schema), so existing databases stay compatible.

Changelog

changelog = "none"
reason    = "Internal change only."

@Mirko-von-Leipzig Mirko-von-Leipzig changed the title chore: mvoe ntx-builder to sqlite framework ntx-builder: move to sqlite framework Jul 17, 2026
Comment on lines +17 to +18
.into_iter()
.next())

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps we should add a row.first() -> Option<T>

Comment on lines +41 to +52
/// Serializes a [`BlockNumber`] to the `i64` used by the `block_num`/`committed_at`/`last_attempt`
/// columns.
pub(crate) fn block_num_to_i64(block_num: BlockNumber) -> i64 {
i64::from(block_num.as_u32())
}

/// Deserializes a `block_num`/`committed_at`/`last_attempt` column value back into a
/// [`BlockNumber`].
#[expect(clippy::cast_sign_loss)]
pub(crate) fn block_num_from_i64(val: i64) -> BlockNumber {
BlockNumber::from(val as u32)
}

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These should be covered with the SQLite codec trait?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some thoughts, leaving inline so we can discuss more easily.

First some organizational ones:

  • I think we should wrap the db crate's read and write tx again here, and then expose the queries / writes as methods instead of free functions.
  • I would prefer separate folder per sqlite query i.e. not bundling multiple per file, and no sql folder.

More important though:

  • Everywhere still has access to the Database struct.
    • This means everywhere can still write if they so choose.
  • I think the SQLite framework should not give back the Database struct on construction.
    • Instead return: (WriteTx, Pool<ReadTx>).
    • That way we cannot mix and match.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants