Default transactions to abort on drop

[Ekleog]

trafficstars

Hey!

Here's an idea for indexed-db-futures v0.5: what if transactions aborted on drop, instead of committing on drop?

This'd make them farther away from the indexed-db standard, for sure, but the indexed-db standard is based on callbacks, which are pretty different from futures anyway. And, in Rust, it's very easy to miss one early-return point, to make sure that returning Err from a function aborts the transaction.

TL;DR:

fn foo() {
    let transaction = [...];
    transaction.add_key_val(...).unwrap().await.unwrap();
    do_some_check(&transaction).await?;
    Ok(())
}

This will (AFAICT) commit the transaction if do_some_check were to return an Err. The behavior I'd expect from the code if just reading it intuitively, would be for the transaction to be aborted.

In order to get the behavior I'd instinctively expect, I need to use the following code, which is quite a bit less pleasant to both write and read:

fn foo() {
    let transaction = [...];
    transaction.add_key_val(...).unwrap().await.unwrap();
    if let Err(e) = do_some_check(&transaction).await {
        transaction.abort().unwrap();
        return Err(e);
    }
    Ok(())
}

WDYT about adding a commit(self) function to transaction, that'd commit it (ie. just drop it), and to have IdbTransaction's Drop implementation abort the transaction if it has not been explicitly committed?

Anyway, I'm just starting using indexed-db-futures, but it already seems much, much more usable than the web-sys version. So, thank you! :D

[Ekleog]

After some more investigation, I learned that this would be a nontrivial feature.

So I decided to go ahead and implement it, and this resulted in the indexed-db crate, that has a misuse-resistant API with transactions that always abort upon errors and never commit early.

Do you want to keep this issue open to track this feature inside indexed_db_futures, or should we close it? :)

[Alorel]

Hey, thanks for bringing this up and sorry I'd abandoned this crate for so long. Let's keep this issue open please - I'll want to do some refactors around the crate and it'll be helpful to have this issue for reference