This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 11350 - [IndexedDB] ObjectStores should have a way to hint that they're "evictable"
Summary: [IndexedDB] ObjectStores should have a way to hint that they're "evictable"
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: Indexed Database API (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Jeremy Orlow
QA Contact: public-webapps-bugzilla
Depends on:
Blocks: 11398
  Show dependency treegraph
Reported: 2010-11-19 12:05 UTC by Jeremy Orlow
Modified: 2015-04-23 16:03 UTC (History)
4 users (show)

See Also:


Description Jeremy Orlow 2010-11-19 12:05:25 UTC
At TPAC, we talked about whether we should make some way for web apps to tell the UA that data is not critical.  Many uses for IndexedDB are such that it's not a big deal if data is discarded, but there are some use cases where it's critical.  For example, the archive of your email for all time might not be critical, but the email you wrote while offline that still hasn't gotten a chance to send yet is.

We discussed what the proper granularity is.  Per record seems very difficult to implement efficiently.  Per database means that you can't have transactions that involve both both classes of data.  So we decided to make it per-objectStore.

createObjectStore's optional parameters will turn into a single optional options object that gets passed in.  So, for example, you would do .createObjectStore("name", {autoIncrement: true, keyPath: "id"}); to create an objectStore with an autoIncrement number stored in the id keyPath and the name of "name".

We'll then add another parameter to the optional options object parameter that is "evictable" which states whether or not the browser can get rid of the data at its discretion.  This will default to false.
Comment 1 Jeremy Orlow 2010-11-25 14:47:31 UTC
storeNames should probably be renamed to objectStoreNames for consistency/clarity too.
Comment 2 Pablo Castro 2011-06-08 00:13:13 UTC
Based on this [1] thread it looks like we all think we should have some sort of evictable store mechanism but that we could add that later on after we land an initial version of the spec.

Resolving this as "LATER".

Comment 3 Joshua Bell 2015-04-23 16:03:08 UTC

In discussions with implementers, this seems to be the wrong direction. See for some more recent thoughts.