This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
storeNames should probably be renamed to objectStoreNames for consistency/clarity too.
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". [1] http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0935.html
LATER -> WONTFIX In discussions with implementers, this seems to be the wrong direction. See https://wiki.whatwg.org/wiki/Storage for some more recent thoughts.