Re: [w3c/IndexedDB] Spec clarification regarding implied steps (Issue #433)

Thanks! This sort of feedback is great. This spec predates the modern style of writing out explicit algorithms, so it's unsurprising that there are still gaps to plug.

> * [Opening a database connection](https://w3c.github.io/IndexedDB/#opening) step 10.8 says `If the upgrade transaction was aborted`, but there is no mention elsewhere in the steps where the `upgrade transaction` comes from. 

Agreed. It looks like an easy fix would be for the "[upgrade a database](https://w3c.github.io/IndexedDB/#upgrade-a-database)" steps to return the transaction.

> * The only way to tell if a transaction was aborted seems to be if [the transaction has an error](https://w3c.github.io/IndexedDB/#transaction-error), but when calling [IDBTransaction::abort()](https://w3c.github.io/IndexedDB/#dom-idbtransaction-abort), the error is set to null (It calls [abort a transaction](https://w3c.github.io/IndexedDB/#abort-a-transaction) with a null parameter).
>   So this abort is not marking the transaction as aborted?

The _intent_ is that an explicit `abort()` does abort the transaction, but the value reported via the [error getter](https://w3c.github.io/IndexedDB/#dom-idbtransaction-error) is null. 

So yeah, that means that the [error state](https://w3c.github.io/IndexedDB/#transaction-error) of a transaction is used incorrectly. A minimal fix probably looks like:

* Defining the [error state](https://w3c.github.io/IndexedDB/#transaction-error) as initially unset, but set to a value (which can include null) if the transaction is aborted.
* Revising the "[abort a transaction](https://w3c.github.io/IndexedDB/#abort-a-transaction)" steps to say "If error is not set, set transaction’s error to error." 

> * In [abort a transaction](https://w3c.github.io/IndexedDB/#abort-a-transaction), step 6.3.1, it says to use `the open request associated with transaction`, but there is no spec steps that sets this anywhere

This is specified as part of "[open request](https://w3c.github.io/IndexedDB/#request-open-request)" - but could be made more explicit as part of "[upgrade a database](https://w3c.github.io/IndexedDB/#upgrade-a-database)" steps. For example, just saying "request's transaction is transaction".

I'll note that the steps to "[asynchronously execute a request](https://w3c.github.io/IndexedDB/#asynchronously-execute-a-request)" don't explicitly associate the transaction with the new request either.

> * In [delete a database](https://w3c.github.io/IndexedDB/#delete-a-database), step 5. wants `the set of all connections associated with db`, but there are no steps to create this association

Yeah, it's just heavily implied in "[database connection](https://w3c.github.io/IndexedDB/#database-connection)" and "[opening a database connection](https://w3c.github.io/IndexedDB/#opening)". Making it explicit would be nice.

> * In [IDBFactory::open](https://w3c.github.io/IndexedDB/#dom-idbfactory-open), step 4 creates a new `open request`, and then dispatches an event to this during step 5.2.3. Then later it is returned as a `IDBOpenDBRequest`. Is the `open request` a IDBRequest? And if so, is there a reason to not create an IDBOpenRequest directly in step 4?

This is a quirk of how and when the spec was written. The spec text mostly deals in abstract constructs and assumes the WebIDL-defined interfaces are the reflection of those in script. So it refers to a "[connection](https://w3c.github.io/IndexedDB/#database-connection)" not an `IDBDatabase`, and a "[request](https://w3c.github.io/IndexedDB/#request-construct)" not an `IDBRequest`. A browser implementer could equate the constructs to the C++ objects, which are distinct from the JS objects.

More recently written specs dispense with that level of abstraction. I'd welcome a future editor reworking this!

PRs welcome for improvements to any/all of the above.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/433#issuecomment-2512330086
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/IndexedDB/issues/433/2512330086@github.com>