The way put() works on a store: overwriting pre-existing fields vs. resetting them

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

The way put() works on a store: overwriting pre-existing fields vs. resetting them

Tony Mobily

I am using several JsonRest stores i my application. In fact, all I am using is JsonRest stores...
In my store, if you put() an object with an _id, the pre-existing fields will be kept. This means that I can make really lean calls, just to change a flag for example, and things will just work.
I am also using the great Cache.js module to cache things up in my application.

The only problem I am having now is that the Memory store works differently to the JsonRest store: with the Memory store, when you put() something with an Id, the new object replaces the old one. Pre-existing fields in the old object, not defined in the new one, are deleted.

This basically means that after a put() with partial fields there will be a discrepancy between what's in the database, and what's in my local cache. This causes a series of headaches.

At the moment, I "fixed" it by changing the put() method in Cache.js:

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

                                var objectToWrite;
                                var originalObject = cachingStore.get( object[cachingStore.idProperty] );

                                if (originalObject ){
                                  objectToWrite = lang.mixin( originalObject, object );

                                } else {
                                   objectToWrite = object;

                                // MERC
                                cachingStore.put(typeof result == "object" && result !== null ? result : objectToWrite, directives);

                                return result; // the result from the put should be dictated by the masterStore and be unaffected by the cachingStore

The original logic (where if an object is returned by the server, it's used as a "current status") is kept. However, pre-existing fields in the cache are "kept" (by actually fetching whatever was in the cache beforehand, and actually storing the result of a mixin).

Is this a sane way to go about it? Any comments/takes on the way I am doing things?