'use strict'
class Item {
constructor() {
this.id = null;
this.name = null;
}
}
let item = new Item();
item.id = 1;
item.name = 'Item 1';
let item2 = new Item();
item2.id = 2;
item2.name = 'Item 2';
let payload = {
'id': '231',
'items': []
};
payload.items.push(item1);
payload.items.push(item2);
let aws = require('aws-sdk');
let dynamodb = new aws.DynamoDB.DocumentClient();
dynamodb.put({'TableName': 'valid-table-name', 'Item': payload}, function (err, data) {
if (err) {
console.log('Err => ', err);
}
});
The above code inserts the payload without the contents of payload.item and does not throw any error.
However, the payload is inserted properly if i stringify the objects being pushed into payload.
payload.items.push(JSON.stringify(item1));
payload.items.push(JSON.stringify(item2));
Can you please let me know if users are expected to only throw in stringified objects to the DocumentClient?
@swarajgiri
The AWS.DynamoDB.DocumentClient accepts JSON objects, but not instantiated objects. The root of this behavior is in how the client converts inputs into a format that DynamoDB understands.
Specifically, you can see what types of inputs are supported by the client by looking at the convertInput function: https://github.com/aws/aws-sdk-js/blob/master/lib/dynamodb/converter.js#L5
You'll notice that typeOf is called on inputs, and for objects instantiated from a function, typeOf returns the function name. Since the function name won't fulfill any of the conditionals, those inputs are ignored. If functions were also converted, you may see some unexpected fields, such as those on the prototype chain, being saved to DynamoDB as well.
I hope that clarifies things! I'm going to close this issue, but feel free to comment or re-open if you want to discuss this further.
stringify would remove the prototype chain. If that's not acceptable for some reason, the sdk should at least throw an error instead of ignoring some part of the item to be inserted.
@swarajgiri
Didn't you indicate stringify worked? If so, I'm not sure what the issue is there. You could also create a function on the prototype to return a plain JSON object as well, in case you were using those classes elsewhere.
@chrisradek - The issue is, as the title suggests, DocumentClient at least should throw an error instead of silently failing
:+1: for throwing an error when there's an error.
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs and link to relevant comments in this thread.
Most helpful comment
:+1: for throwing an error when there's an error.