<< We can do synchronous tests against the schema as it is feasible for implementations to maintain a copy of the current schema for an open connection in memory in the same thread/process as script. (Or at least, no implementer has complained.) >>
Oh cool. So I could have a 3rd party component in my app that can then test the schema directly and run certain functions only if some combination of conditions are met and having those test be synchronous makes the tests simple. For example, does xyz object store exist and does it have the right indices. If so then the component would run. Else it wouldn't. I get the thing about the cost of looking up a value and why that has to be asynchronous. Jonas, I have no request per se, just super curious about the rationalizations around v2 APIs, so I might have questions or curiosity that are expressed indirectly as suggestion. Sometimes I say naive things and other times the suggestions may be directly useful or bring up some other thoughts. I'll try to minimize the confusion. But do look out there: almost every front end developer I've talked to things IndexedDB is less than usable and the library makers haven't yet provided something both truly solid and worth throwing the native APIs for, so I'm trying to understand things better for myself so I can help build a better library but would rather have the IDB native API come to a point in its evolution where front end developers would be able to consume it directly with no intervening layer, and that's why asking and making sometimes dumb and sometimes useful suggestions, to try and understand how the IDB designers think. If that actually makes any sense. Sent from my iPhone > On Jun 23, 2014, at 2:22 PM, Joshua Bell <[email protected]> wrote: > > We can do synchronous tests against the schema as it is feasible for > implementations to maintain a copy of the current schema for an open > connection in memory in the same thread/process as script. (Or at least, no > implementer has complained.)
