- From: <bugzilla@jessica.w3.org>
- Date: Wed, 09 Jun 2010 13:00:24 +0000
- To: public-webapps@w3.org
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.
Received on Wednesday, 9 June 2010 13:00:26 UTC