- Newest
- Most votes
- Most comments
It's always been this way. It's hard from the outside to reliably answer "why" questions.
This StackOverflow post shows a technique to assign and append in one call: https://stackoverflow.com/questions/66534235/invalid-updateexpression-two-document-paths-overlap-with-each-other-must-remov
Hello @MassimilianoA,
I understand that I use it twice, and the message is clear on what must happen.
My question is WHY this is the case? I don't see how these operations would clash. One operation is updating existing items, and the other is merely adding new items, that were never there in the 1st place. Why would DynamoDB stop me from doing that? And I have been using the specific code that generates this for a while now, and I find it hard to believe that this specific situation did not happen before.
I have also tried REMOVE
followed by a SET list_append
, and that also does not work. In that case, it is not operations over the same field in the same SET
statement, but it fails the same way. Seems like this is a blanket validation rule applied over the expression, disregarding the fact that the field is a list.
The use case is as I mentioned in my question: I do not want multiple update events in my table stream, if I can avoid those. And it would reduces the likelihood of issues due to multiple concurrent updates.
So, summarizing:
- Did this change, or was it always like this?
- Why shouldn't it be supported? I understand this limitation for other field types, but not for lists.
- Should I expect a fix, or should I just go ahead and split the operations?
The problem is in the SET expression, where you are referring twice to the same attribute #integrations
. You need to remove one of #integrations[1] = :update1
or #integrations = list_append(...)
to make the expression valid.
This means that you cannot update an item in the list and append new items in a single operations.
Sharing some additional information about the specific use case (ie the need to update the 2nd element of the list at the same time that you are adding new elements) might help in providing alternative solutions to achieve your goal of minimizing the number of operations on the table.
Relevant content
- asked 2 years ago
- asked 7 years ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a month ago
- AWS OFFICIALUpdated 8 days ago
- AWS OFFICIALUpdated a year ago
Very dirty trick. I will take it. Thanks mate!