feat: Add migration for keyset_id as foreign key in SQLite database #634

2025-03-06T15:58:54Z

thesimplekid commented

2025-03-06 15:58:54 +00:00

(Migrated from github.com)

Description

closes #628

Notes to the reviewers

Suggested CHANGELOG Updates

CHANGED

ADDED

REMOVED

FIXED

Checklist

I followed the code style guidelines
I ran just final-check before committing

### Description  ----- closes #628 ### Notes to the reviewers  ----- ### Suggested [CHANGELOG](https://github.com/cashubtc/cdk/blob/main/CHANGELOG.md) Updates  #### CHANGED #### ADDED #### REMOVED #### FIXED ---- ### Checklist * [x] I followed the [code style guidelines](https://github.com/cashubtc/cdk/blob/main/CODE_STYLE.md) * [x] I ran `just final-check` before committing

crodas (Migrated from github.com) reviewed

2025-03-06 15:58:54 +00:00

thesimplekid commented

2025-03-06 16:42:04 +00:00

(Migrated from github.com)

cc @ok300

ok300 (Migrated from github.com) reviewed

2025-03-06 18:02:37 +00:00

crates/cdk-sqlite/src/mint/migrations/20250306165813_keyset_id_as_foreign_key.sql

Do these have to be created at the beginning, when they'll be (re-)created anyway further down below?

crates/cdk-sqlite/src/mint/mod.rs

					
				@ -878,1 +890,4 @@

				                tracing::error!("Error adding proof: {:?}", err);

				                transaction.rollback().await.map_err(Error::from)?;

				                return Err(Error::from(err).into());

				            }

The error matching is becoming quite complex. Instead it, why not change the query to INSERT ON CONFLICT IGNORE or INSERT OR IGNORE? I think that would automatically cover both relevant error types:

proof is already known (conflict on proof's PK y)
conflict on FK constraint

We wouldn't know why a proof wasn't inserted, but if that's important, we could 1-2 validation steps before the query (check if proof's PK y is known, check if foreign key is valid).

The error matching is becoming quite complex. Instead it, why not change the query to `INSERT ON CONFLICT IGNORE` or `INSERT OR IGNORE`? I think that would automatically cover both relevant error types: - proof is already known (conflict on proof's PK `y`) - conflict on FK constraint We wouldn't know _why_ a proof wasn't inserted, but if that's important, we could 1-2 validation steps before the query (check if proof's PK `y` is known, check if foreign key is valid).

thesimplekid (Migrated from github.com) reviewed

2025-03-07 21:15:30 +00:00

crates/cdk-sqlite/src/mint/mod.rs

					
				@ -878,1 +890,4 @@

				                tracing::error!("Error adding proof: {:?}", err);

				                transaction.rollback().await.map_err(Error::from)?;

				                return Err(Error::from(err).into());

				            }

Address in c6f3318

I think we still want to error and rollback when there is a fk error

Address in c6f3318 I think we still want to error and rollback when there is a fk error

thesimplekid (Migrated from github.com) reviewed

2025-03-07 21:15:40 +00:00

crates/cdk-sqlite/src/mint/migrations/20250306165813_keyset_id_as_foreign_key.sql

Good point

Sign in to join this conversation.

No reviewers

crodas

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

cashubtc/cdk!634

Rows
Columns