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 11351 - [IndexedDB] Should we have a maximum key size (or something like that)?
Summary: [IndexedDB] Should we have a maximum key size (or something like that)?
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: Indexed Database API (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: This bug has no owner yet - up for the taking
QA Contact: public-webapps-bugzilla
Depends on:
Reported: 2010-11-19 12:15 UTC by Jeremy Orlow
Modified: 2011-03-08 03:43 UTC (History)
3 users (show)

See Also:


Description Jeremy Orlow 2010-11-19 12:15:32 UTC
Should we have some sort of maximum key size for what's in IndexedDB?

* Most other databases do.
* It's very difficult to handle them efficiently.
* Many backing storage engines have limits.
(These could be worked around by an implementation storing just the first part of a particularly big key in the backing engine and then looks up the rest in the value when necessary.  This clearly would add a lot of complexity and slow things down.)

* Pushing complexity onto the web developer.
* May break web apps in ways authors don't anticipate.

There are probably other pros and cons that I'm forgetting (please bring them up if so!).

Just looking at this list, I guess I'm leaning towards _not_ limiting the maximum key size and instead pushing it onto implementations to do the hard work here.  If so, we should probably have some normative text about how bigger keys will probably not be handled very efficiently.
Comment 1 Jonas Sicking (Not reading bugmail) 2011-03-08 03:43:29 UTC
This was discussed on the list and it seems like there was agreement not to put in any hard limits here.