#316: IndexedDB Transaction Explicit Commit API

Visit on Github.

Opened Oct 30, 2018

こんにちはTAG!

I'm requesting a TAG review of:

Further details (optional):

  • Relevant time constraints or deadlines: Preferably before the end of this quarter.
  • I have reviewed the TAG's API Design Principles

We'd prefer the TAG provide feedback as (please select one):

  • open issues in our Github repo for each point of feedback
  • open a single issue in our Github repo for the entire review
  • leave review feedback as a comment in this issue and @-notify [github usernames]

Discussions

Discussed Jan 15, 2019 (See Github)

Kenneth: Well, it's one function! Has a good explainer. Originally, IDB is auto-committing. This will allow folks to commit when folks want it to be commitment; it will still auto-commit but will be later. There is some bikeshedding on the name, since it could be misunderstood.

Alex: Does impact the conversation about retro-fitting IDB into Promise. IDB auto-close was end of micro-task or task; so I don't see this as really controversial. Does anyone have data that shows this can really increase throughput?

Kenneth: No one has brought this up with me. Folks may think that they may need to call "commit".

Alex: Can I call "commit" twice? I would like to see example code that covers the error conditions/handling? Otherwise, this is a very very good explainer!

Dan: Kenneth, you can leave some feedback on the issue?

Kenneth: Yes, and I want to sync with Sangwhan too.

Comment by @torgo Jan 15, 2019 (See Github)

Discussed on call 15-jan.

Comment by @kenchris Jan 16, 2019 (See Github)

First of all, thanks a lot of the excellent explainer! We noticed that the API can throw so we would like to see some examples of how to do proper error handling.

I understand the worry that people will think they have to manually call commit() so what about renaming it to something like forceCommit() which feels like something you would only call if you know what you are doing

Discussed Jan 22, 2019 (See Github)

Kenneth: We finished this last week?

Sangwhan: Our main point of feedback was there was 'commit' and we wanted to call it 'forcecommit'? I'm OK with either one. Looked over a variety of other APIs in other platforms...

Kenneth: not all platforms do auto-commit though right?

Sangwhan: It depends :-)

Kenneth: will leave an addition comment.

Comment by @kenchris Jan 22, 2019 (See Github)

@andreas-butler, @dmurph please see above

Comment by @andreas-butler Jan 23, 2019 (See Github)

Hi Ken,

Thanks for the feedback and the bump. We agree that the commit -> forceCommit rename is a good idea, and we will be adding examples of error handling to the explainer.

Best, Andreas

Comment by @andreas-butler Jan 23, 2019 (See Github)

@inexorabletash raised a point to keep in consideration going forward with the rename: there are plans to, at some point in the future, design and add a feature to indexeddb that allows developers to forego autocommit entirely and commit only when they're ready. If this feature is implemented as another type of 'commit' call it is worth considering if there will be problems naming it if the name 'forceCommit' has already been taken here.

Comment by @cynthia Jan 24, 2019 (See Github)

That is a good point, I don’t think any of us are in the position of “this may not ship unless it is renamed to force” so that sounds good to me.

Comment by @kenchris Apr 10, 2019 (See Github)

Thanks for flying TAG, this looks fine to us