feat: add consumed capacity to update response

[yoitsro]

When updating an item, there is the option to return the consumed capacity. http://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateItem.html#DDB-UpdateItem-request-ReturnConsumedCapacity If it is returned, it is appended to the response under the ConsumedCapacity key.

[coveralls]

Coverage decreased (-0.08%) to 98.551% when pulling d78139f6c6518bd9cb0514a432561b3e815fd592 on yoitsro:patch-1 into 6fc96c8b75fc125da0dd503f55f4c79fb3af6ee3 on clarkie:master.

[clarkie]

Thanks for your contribution. Could you add some usage documentation to support your change.

Thanks

[yoitsro]

Hey @clarkie. Check that out. Let me know if you need anything else.

[coveralls]

Coverage decreased (-0.08%) to 98.551% when pulling 3365c98c69f57eab142a9d7ccee6ccd221096d4f on yoitsro:patch-1 into 6fc96c8b75fc125da0dd503f55f4c79fb3af6ee3 on clarkie:master.

[clarkie]

Ah ok, that makes sense. Would it be possible to add a test for this?

Thanks again for your contribution.

[cdhowie]

I am a bit hesitant to add this contextual information directly as a third parameter to the callback, for a few reasons:

• If we want to add more contextual information later, we need to add more parameters. Some parameters may wind up being unused, but the caller still has to declare them. I think it makes more sense to return an object of contextual information, to future-proof this. Then we can set the relevant keys on that object and not have to change the number of parameters to add more/different contextual information.
• When dynogels is promisified, how the contextual information gets conveyed depends on the promise library being used. Promises can't resolve to multiple values, so some promise libraries will -- if passed multiple success values -- aggregate them into an array, which means the result type of the promise will depend on whether contextual information is available. Other libraries will take the first success argument and ignore the rest, discarding the contextual information. I'm not sure there's necessarily a good solution to this problem, however. (We could create a new object inheriting the model object, add the contextual information to that, and call back with that object, but that feels like a brittle hack.)

[jkav77]

I agree with @cdhowie that adding a third parameter to the callback function is suboptimal. This is inconsistent with the rest of the library's callback functions as well. Is there a different way to make this information available?

Also, couldn't you request consumed capacity for other database operations? Why just for update?