[Bug 11351] New: [IndexedDB] Should we have a maximum key size (or something like that)?

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11351

           Summary: [IndexedDB] Should we have a maximum key size (or
                    something like that)?
           Product: WebAppsWG
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Indexed Database API
        AssignedTo: dave.null@w3.org
        ReportedBy: jorlow@chromium.org
         QAContact: member-webapi-cvs@w3.org
                CC: mike@w3.org, public-webapps@w3.org


Should we have some sort of maximum key size for what's in IndexedDB?

Pros:
* 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.)

Cons:
* 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.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Friday, 19 November 2010 12:15:42 UTC