Cache.js deletes element while waiting: necessary?

[mercmobily]

Hi,

Cache.js has the following lines:

 put: function (object, directives) {
        // first remove from the cache, so it is empty until we get a response from the master store
        var cachingStore = this.cachingStore;
        cachingStore.remove((directives && directives.id) || this.getIdentity(object));
        return when(this.inherited(arguments), function (result) {

That cachingStore.remove is giving me a lot of grief, because I am listening to update events:

 store.on( 'add,update,delete', function( event ){
            var first = store.memCache.data[ 0 ];

And the problem is that when the listener runs, the cache is effectively missing the element (and I need it to be there).

Why are we deleting that element? This is what used to happen with Dojo's store... but is it strictly necessary? Isn't it a borderline bug, to have an incomplete cache for cached stores? Is there any chance we could make that deletion optional? (it really throws a spanner in the works for me)

[makario]

I too experienced a lot of grief while listening to updates because of this; ended up having to remove that line.

I understand that the reason for deletion is that the put() implementation of the cachingStore is asynchronous and can potentially take a "long time", and you don't want the existing item to be fetched since it's technically obsolete.

But in my opinion, fetching an obsolete item is not much worse than a cache miss that could maybe possibly happen in a really really small window of time before the put() operation completes. It becomes even less of an issue since if you're listening for updates.

[kitsonk]

Personal opinion, I don't see why we go ahead and assume the "best" with .put() and update the cache and then re-update when master resolves or remove when master rejects. I will work up a patch.