Re: [IndexedDB] Design Flaws: Not Stateless, Not Treating Objects As Opaque

On 31 Mar 2011, at 7:27 PM, Jeremy Orlow wrote:

>> 1. Provide the application with a first-class means to manage indexes at time of putting/deleting objects.
> 
> I'm OK with doing this for v1 if the others are.  It doesn't seem like that big of an addition and it would give a decent amount of additional flexibility.

Thanks Jeremy that would be great.

>> (reduces serialization/deserialization overhead where application already has the object as a string)
> 
> I'm not sure why you think this would reduce overhead.

How long would it take an iPad to JSON deserialize/serialize 500 / 5,000 / 50,000 / 500,000 / 5,000,000 2KB objects? That's a reasonable device and those are reasonable workloads. In it's present state, IndexedDB needs to do this every time setVersion is called with a createIndex in there... you see the problem is there's no way for the application to control this. The application would arguably be able to find better ways of migrating indexes than using key paths which necessitate deserialization/serialization to be performed on the client. For instance, you could use batch jobs on the server to do this on behalf of clients, and this would make sense especially where many clients/devices share the same objects. With IndexedDB this is not possible. With pure storage primitives it would have been possible. This is just one use-case, and for every one of these there will be plenty more.

> Like I said above, although I think we should make it possible to operate more statelessly, I don't see a reason we need to remove stuff like this. Some users will find it more convenient to work this way.

Agreed on both counts. It is clearly too late to remove it now. But it may be a good idea in future to keep the focus on providing low-level primitives rather than convenience features, since the latter often get in the way of the former.

Received on Thursday, 31 March 2011 18:47:08 UTC