You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The hosted_db module doesn't abstract away database functionality much, and breaks the abstraction in a few places
In the main hosted_db.rs, there is a run_query that matches on db_type. We only support one DB type for now (SQLite), and so this function throws an error for any other db_type.
The SQLite-specific code does a mix of handling sandboxing (something that shouldn't be DB-specific) and SQLite-specific querying
Sandboxing assumed you're running queries on SQLite with no abstraction
Outside of the querying logic, there's also server::snapshots::execution, which calls directly into the SQLite backup facilities. Ideally that would also be in some form of abstraction.
All of this adds up to
Create a HostedDb trait (like ayb_db::db_interfaces::AybDb)
Specific implementations like SqliteHostedDb and DuckDbHostedDb would then implement query (with safe/unsafe variants) and backup
Isolation should be orthogonal to the HostedDb. Perhaps the query code in the HostedDb can pass whatever information it needs to an isolated context to run inside of it.
The text was updated successfully, but these errors were encountered:
run_query
that matches ondb_type
. We only support one DB type for now (SQLite), and so this function throws an error for any otherdb_type
.server::snapshots::execution
, which calls directly into the SQLite backup facilities. Ideally that would also be in some form of abstraction.HostedDb
trait (likeayb_db::db_interfaces::AybDb
)SqliteHostedDb
andDuckDbHostedDb
would then implementquery
(with safe/unsafe variants) andbackup
HostedDb
. Perhaps thequery
code in theHostedDb
can pass whatever information it needs to an isolated context to run inside of it.The text was updated successfully, but these errors were encountered: