How to delete an SQLite database for the various backends

[LucaCappelletti94]

Hi,

How do I delete an SQLite database for the various backends?

I see that for IDB there is this delete_db private method, for sahpool I am not sure which methods may be around, and I guess that for the in-memory one every refresh is a clear.

Maybe there should be a trait standardizing how to drop the DB across backends?

Best,
Luca

[Spxg]

I see that for IDB there is this delete_db private method,

RelaxedIdbUtil exports this method.

sqlite-wasm-rs/sqlite-wasm-rs/src/vfs/relaxed_idb.rs

Line 783 in acda9fd

pub fn delete_db(&self, name: &str) -> Result<WaitCommit> {

for sahpool I am not sure which methods may be around

For sahpool, the corresponding method is OpfsSAHPoolUtil's unlink.

Since sahpool is ported from sqlite-wasm, the method names are the same as sqlite-wasm. I expect the next major version to introduce breaking changes and rename these methods.

I guess that for the in-memory one every refresh is a clear.

Yes, however, memvfs also provides a delete_db method.

Maybe there should be a trait standardizing how to drop the DB across backends?

This is possible, but it requires more design because the delete behavior of different VFS is different. For sahpool and memvfs, delete_db is completed immediately. For relaxedidb, delete_db will immediately delete the database in memory and return a WaitCommit future, user can await that for the database to be deleted from the indexed db.

[LucaCappelletti94]

I guess we could make two traits, DeleteDB and DeleteDBAsync where the first is implemented only for SAHPool and memvfs while the latter can be implemented for all?

[Spxg]

The DeleteDBAsync trait is not quite accurate.

There is a reason why RelaxedIdb is designed as fn delete_db() -> WaitCommit instead of async fn delete_db(). Because the calling place may not be in an asynchronous context, for RelaxedIdb, deleting the data in memory immediately can be considered that the database has been deleted, unless it is reloaded into memory before IndexedDb deletes it.

And there is also the import_db and export_db methods. I think there needs to be a Util trait.

Anyway, thanks for your feedback, but I'm not ready to provide them with a unified trait. For users, they can make trait based on their own usage scenarios.