On 02 Mar 2011, at 1:31 PM, Jonas Sicking wrote: > I agree that we are currently enforcing a bit of schema due to the way > indexes work. However I think it's a good approach for an initial > version of this API as it covers the most simple use cases. Note that > the more complex use cases are still very possible by simply using a > separate objectStore as an index and manually add/remove things there. > > I still believe that using a function, which is persisted in the > database, is very doable. And yes, the function needs to be stateless > and it needs to be possible to change the set of functions which > manage the set of indexes associated with a given objectStore > (probably by simply allowing indexes to be created and removed, which > is already the case). > > / Jonas
Thank you Jonas, I'm using your multi objectStore trick at the moment to store indexes. It just seems that the most direct way of doing all of this, would just be to let the application pass in the relevant index references when it makes put or delete calls. IDB is almost becoming a Rube Goldberg device trying to find other ways of doing this. The reason I bring it up, is because I just made this same change with my server database, which used to require schema knowledge, so it could compute indexes etc., and then I realized this could all be eliminated completely by just passing indexes per put and delete call. I really don't think IDB should try and dip it's toes into application state in the first place, let alone try and keep up with application state thereafter. What is the motivation for doing that? It's not absolutely necessary. It's an assumption that is bloating almost every part of the spec. It's not the killer feature of IDB, and it's getting in the way of things that could be, such as indexing and querying. If version 1 is done right, there will be no need for version 2. There's been a tremendous amount of discussion regarding IDB and people like yourself and Jeremy have certainly contributed massively, but I do get the feeling (as may you) that version 2 is becoming a stopover for things that have not been thought through completely, for which a solution is not yet clear, something's not right. I only say this from recently re-writing a database after making the same mistake.
