Weird update behaviour with undefined

[radarfox]

Hello Jason,

I have found a bug in this adapter. It handles "undefined" quite inconsistently. See plnkr I created for that:

http://plnkr.co/edit/vqJnw06G0iz6GMxWaqu0

[jmdobry]

The value is indeed saved as undefined. The behavior you're seeing is controlled by JSData's onConflict option, meaning the strategy it uses to merge data into the store when the data is already in the store. The default value for onConflict is "merge", but if in your plunker you set onConflict to "replace" on your resource definition, then the behavior will be more what you expect. undefined is generally treated as "property is not set". If you want to set a property to a non-value, then I suggest you set it null, which is representable in JSON.

[radarfox]

I am affraid that, replace isn't an option for me, because it would delete all other data not included in DSUpdate, am I right?

Also null is not very good option too, as it's acually stored in localStorage and depleting it's quota.

Currenty I use this hotfix, to remove all undefined and prevent entering this weird behaviour:

var modelData = {value: undefined};
angular.forEach(modelData, function (value, key) {
    if (angular.isUndefined(value)) {
        delete modelData[key];
    }
});
model.DSUpdate(modelData);

Also I'm thinking about switching to DSSave, which should work, and shouldn't have any significant performance loses with localStorage compared to usage over http, am I right?

resource.create({value: true}).then(function (model) {
  model.value = undefined;
  model.DSSave();
})

Still i find current DSUpdate behavior quite frustrating, as I have to make sure no undefined gets in it. You should definitely fix that, either with applying undefined (as localStorage adapter does), or by ignoring it (as cache does), but not both at same time.

For myself i would prefer the first (applying) solution, which I find more widely used and also consistent with how DSSave works.