http://www.w3.org/Bugs/Public/show_bug.cgi?id=9888
Summary: Constants are not accessible when they're needed for
most IndexedDB interfaces.
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Indexed Database API
AssignedTo: nikunj.mehta@oracle.com
ReportedBy: jorlow@chromium.org
QAContact: member-webapi-cvs@w3.org
CC: mike@w3.org, public-webapps@w3.org
In indexedDB, there are many cases where it's impossible to access a constant.
For example, if I'm trying to create a key range, I might want to pass in
KeyRange.LEFT_OPEN. Unfortunately, the only way to get at LEFT_OPEN is to
create a KeyRange. This is true of pretty much all the objects and their
constants.
Another example is that you can't access the error constants without causing an
exception so you can get an IDBDatabaseException object. But that's not even
possible outside of workers.
We could create global constructors, but it doesn't seem worth it to pollute
the namespace. We could pull all the constants up one level. For example, the
constants for Cursors would be added to IDBIndexes and IDBObjectstores since
those are both the places where you'd create a cursor. If we wanted to avoid
the duplication, we could even pull all the constants up to the
IndexedDatabaseRequest level (where mozilla's proposal suggests we put the
keyRange constructors).
Until this is fixed, people using IndexedDB will need to use pretty ugly hacks
to get at the constants or hard code in the numbers themselves.
--
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.