I'm not sure how far along they are toward the milestone. I think it may be delayed a few days anyway. I use the SVN version anyway, so it doesn't much matter to me, as I grab the updates as they happen. The best thing to happen to this version is the Grid.

The documentation process is as open as we can make it. If you send in a CLA, we an give you editing perms on the book, and until then you can comment on any page. The editing process is outlined in the book itself, and getting started as a contributor to the book is as simple as sending Craig an email.

Regards

As referenced by the bug tracker link on the left menu
-Karl

First thing I want to say is thank you for the interest in dojo.data! I do appreciate your time to look at it. The second is what you think is a bug actually isn't. That's an intentional store design decision for ItemFileWriteStore (Just one of many datastores that exist). Yes, it may seem odd as to why we're using an ever growing array, but there is a reason. Let me explain; it all has to do with the dojo.data.api.Identity interface. (http://dojotoolkit.org/book/dojo-book-0-9/part-3-programmatic-dijit-and-...)

The dojo.data.api.Identity interface is intended to allow for unique identiication of an item. This means that if you know the identity of an item, you can look that specific item back up without having to do a query (fetchItemByIdentity). ItemFile*Store supports the identity interface and it does so in two ways.

1.) Users can specify an 'identifier' in their dataset handed to the store. The identifier is nothing more than the name of an attribute that will have a unique value for that item alone out of all the items in the store.

2.) If users do not set an identifier, the store assigns you one so that the store can still meet the identity interface. The simplest and least code implementation determined at the time for that was index position in the _arrayOfAllItems array. Using the array position in that case allowed us to not have another associative map to track it. But, the caveat is ... you cannot ever change the array position of an item in _arrayOfAllItems, as that would change the identity of the item (which is supposed to be an immutable lookup key). So ... while your suggested patch does indeed compress the array back down ... you break Identity support with it. Ultimately, the reason we chose this implementation path at the time for this store was that is was minimal code to do (And size does matter. Dojo does a lot to keep things small). It was a trade off between what looked like more code (code to calculate a unique id, which probably would have just been a counter), plus maintaining the map, and so on. We (the implementors of that store) figured that for 95% of users the fact that it grows the array wouldn't even be noticeable. And for the other 5%, honestly, if you are creating and deleting thousands upon thousands of items (when you'd actually start noticing it) without closing the browser even once or relogging back in ... ItemFile*Store isn't really the datastore you would want to be using. You would want one that works with a back end service, such as a database or the like and doesn't keep everything in the browser, or do sorting in thebrowser, or querying. Huge numbers of items really are best handed by a backend server, where the datastore is just a small shim layer ontop of the service interface.

The whole purpose of the dojo.data API was to define a generic interface to write a datastore to. And as long as people conformed to the API, it should work well with dojo.data enabled widgets with little to no change to widget code (http://dojotoolkit.org/book/dojo-book-0-9/part-3-programmatic-dijit-and-...). Also, it's effectively impossible to write one store implementation that works for every case people would want. ItemFile*Store is not the 'ultimate' store for all use cases; it's just one of many implementations (there are others in dojox.data for example), and even others provided by companies like SnapLogic. The best thing to always do is look at what your ultimate goal is and how much creation/deleting of items you need to do (and how much data in general you are working with), when deciding on what datastore to use, or if you should write one specific to your data services. ImtemFile*Store is a great store for prototyping and working with moderate data sizes fairly well. It performs decently, implements every API defined by Dojo.data, and is pretty flexible ... but again, it's not the ultimate store and there will be cases you have to write a custom one for your application and data services. Now, if your services are generic and you're willing to sign a CLA and contribute your implementation to dojo with Unit Tests, we are more than happy to receive contributions! The Dojo Toolkit lives off the good work of its contributors and we're always hoping for more good contributors. :-)

Anyway, I'll cut this comment off and say again thank you for your interest in dojo.data, but your suggested fix to what was an accepted performance limitation at the time of the store design would actually break the store. A more complete fix would have to remove the dependency on the index position in the store as the identifier in the case where the dataset had no identifier attribute specified.

Sincerely,
-- Jared Jurkiewicz