Open SamVerschueren opened 5 years ago
When reading this again, it made me wonder that actually reading every record first before doing an upsert might not be very good performance wise, especially when doing multiple upsert calls at once for instance. Have to skim through the dynamodb documentation to see if there are other ways to solve this.
If we have an employee like this
And we call an upsert like this
The result will be
Which is not correct, the
Hobbies
property should be removed.Solution
The solution would be to make all
buildRawQuery()
methods async. The reason is that for this to work, we need to retrieve the record first (with the key provided), and crossmatch the properties. All the properties that are not provided in the new object, should be unset. So for this to work, we need to call an async action in thebuildRawQuery()
method. To make it consistent, we should mark them all asasync
.At first, we thought about implementing it as follows. Remove the original record and insert a new record within a transaction to make sure we don't loose data. The reason it doesn't work is that this would not allow you to use a
upsert
call within a transaction because a transaction within a transaction is not supported.