Migration from vogels: undefined fields make update operation to fail about dynogels HOT 8 CLOSED

DynamoDB doesn't permit undefined values in the update expression. What's the desired behavior for undefined attributes? Should dynogels just filter them out and ignore them on the update or should they be deleted from Dynamo?

from dynogels.

I suppose the driver should omit this values before sending them to DynamoDB.
Vogels.js is doing that way because my tests didn't fail (neither with null values nor undefined).
By using dynogels I see the only and more comfortable approach is to use a lodash 'omit' function (or similar module) before sending the data to the .update method.

from dynogels.

I think this is a related issue, so I'll put it here.

When you set a field inside an object to null in Model.update, it returns the object with that field set to null, but a subsequent Model.get returns the object with the field missing. This is inconsistent and seems like it will result in hard to catch bugs. Vogels' Model.update returns the object with the field stripped, just like it does from a subsequence Model.get.

E.g.,

in Vogels, update and get return the same value

// Vogels (using vogels-promisified)

var myModel = await Model.updateAsync({vars:{foo:null});
console.log('%j', myModel.get('vars')); // {}

var freshModel = await Model.getAsync('theidofthemodel');
console.log('%j', freshModel.get('vars')); // {}

in Dynogels, update and get return different values

// Dynogels (using dynogels-promisified)

var myModel = await Model.updateAsync({vars:{foo:null});
console.log('%j', myModel.get('vars')); // {foo:null}

var freshModel = await Model.getAsync('theidofthemodel');
console.log('%j', freshModel.get('vars')); // {}

from dynogels.

Closing as stale

from dynogels.

@dangerginger - Should this issue stay open? The issue I was seeing (different results returned by update versus get) was serious enough that I didn't end up using dynogels.

from dynogels.

@aneilbaboo I think your issue is totally separate. Regarding @endymion00's original issue I think he was relying on undocumented behavior of vogels to treat undefined properties as a noop.

I think what you described is a bug though. Dynogels doesn't allow null values so the result from update should be the same as in get as you showed in your example: {}.

from dynogels.

Makes sense. I'll create a new issue and add a script that demonstrates the problem.

from dynogels.

Actually, it looks like the issue is fixed in the latest version.

from dynogels.