-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Record Instance Update #59
Comments
I ended up moving to an upsert which returns the final object... sadly was a bit hacky because To handle this I created a
I then created a
This is severely limiting due to the fact that the class and all instances share the same client - this means ALL updates must return 'ALL_NEW' attributes; there is no way to (safely) change that value in a multi-threaded environment (using Shoryuken for processing SQS messages and reading/writing Dynamo). |
I see what you're getting at (and I think a V2 rev of this library may be in the works to address some API concerns such as these), but I'm curious for some more details of what you're trying to do:
Is that a problem? The idea of conditional writes was that if multiple processes are trying to make the same record, you would want to halt, or use |
In one of my use cases forcing would be the appropriate thing to do because we were completely overriding records; in another use case we only wanted to update the attributes provided. Update and returning the record came into play because I want to provide an update to one column while reading another column at the same time. Maybe the functional gap is that Record.update returns a raw DynamoDB Client response rather than a record object. My |
Adding as a feature request to support client options for self.update and other variants. update() |
Right now
save
(orsave!
) encapsulates the selection between a put and an update, with the ability to force put. I recently wanted a "find or create" method, and naively did:I end up receiving the conditional write exception because some other process is trying to create the same record.
To fix this, I moved to using an update:
However, we have a GSI which is dynamically generated from the values which
update
never takes into account (see issue #58). Thus, the preferred solution would be:To achieve this I copied the
else
statement fromItemOperations#_perform_save
which builds an update request for dirty columns and creates the record if it does not already exist; henceupsert
.The text was updated successfully, but these errors were encountered: