Commit Graph

4 Commits

Author SHA1 Message Date
C
ad8f1ece5c Working on a better database abstraction (#931)
* Working on a better database abstraction

After [this question in the chat](https://matrix.to/#/!oJFtttFHGfnTGrIjvD:matrix.cashu.space/$oJFtttFHGfnTGrIjvD:matrix.cashu.space/$I5ZtjJtBM0ctltThDYpoCwClZFlM6PHzf8q2Rjqmso8)
regarding a database transaction within the same function, I realized a few
design flaws in our SQL database abstraction, particularly regarding
transactions.

1. Our upper abstraction got it right, where a transaction is bound with `&mut
   self`, so Rust knows how to handle its lifetime with' async/await'.
2. The raw database does not; instead, it returns &self, and beginning a
   transaction takes &self as well, which is problematic for Rust, but that's not
   all. It is fundamentally wrong. A transaction should take &mut self when
   beginning a transaction, as that connection is bound to a transaction and
   should not be returned to the pool. Currently, that responsibility lies with
   the implementor. If a mistake is made, a transaction could be executed in two
   or more connections.
3. The way a database is bound to our store layer is through a single struct,
   which may or may not internally utilize our connection pool. This is also
   another design flow, in this PR, a connection pool is owned, and to use a
   connection, it should be requested, and that connection is reference with
   mutable when beginning a transaction

* Improve the abstraction with fewer generics

As suggested by @thesimplekid

* Add BEGIN IMMEDIATE for SQLite
2025-08-06 07:58:03 +01:00
Cesar Rodas
1f85d0fd7a Changes
1. Fix migration to avoid re-running migration twice
2. Remove tokio dependency
2025-07-29 11:31:28 -03:00
Cesar Rodas
034af74013 Add Cache to SQL stmt
The cache will store the placeholders and if possible the RAW SQL with position
placeholders, to avoid repetitive computations
2025-07-29 11:31:28 -03:00
Cesar Rodas
349c773406 Introduce cdk-sql-common
The primary purpose of this new crate is to have a common and shared codebase
for all SQL storage systems. It would force us to write standard SQL using best
practices for all databases.

This crate has been extracted from #878
2025-07-29 11:31:23 -03:00