Auto-generated property "entity" interferes with update about dynamodb-toolbox HOT 6 CLOSED

I think this library is handling things in line with DynamoDB best practices and the intent of the underlying APIs.

In your example you are sending the whole fooFromDB entity in the Foos.update call, but the underlying UpdateItem API updates items with an UpdateExpression - i.e. it's built for only sending the changes.

I'd update the name like this:

await Foos.update({
    id: foo.id,
    name: 'Bob'
);

Sending partial updates means you don't end up clobbering concurrent, non-overlapping writes.

from dynamodb-toolbox.

I should also point out that the same test code fails (for the same reason) if you use put() instead of update(). The workaround still applies in either case.

Whether or not update() should support my first example, I'll leave up to Jeremy.

from dynamodb-toolbox.

That's a fair point on put(), and maybe for the sake of consistency update() should work the same way.

What should happen in the case where the entity passed in doesn't match the Entity object?

1. Save it anyway
2. Error out
3. Silently use what's defined in the Entity object?

from dynamodb-toolbox.

Sorry for the late reply. Looking at this now.

from dynamodb-toolbox.

This makes sense. The entity attribute could easily be stripped out when writing both updates and puts, but I'm wondering what we should do with the created and modified times. entity makes sense not to be overwritten, but created definitely should be updated. Perhaps modified should be stripped out as well?

from dynamodb-toolbox.

I've decided to leave _et field manipulation in. You probably should not modify the _et field directly, but you have the ability to if you like. I've added a patch that adds the entity alias to the attributes, so your update will now work correctly.

from dynamodb-toolbox.