DynamoDB Update operation without using the Key attribute

Question

The use case: I have a bid table which holds the bid on Loades. One Load can have multiple Bids. The Bid status is new for every bid. Once the bid is accepted by the Admin(The person who put that Load up for bidding) then I need to change the status for that particular bid as "Accepted" and for other bids on the same Load the status should be "rejected".

Table Definition: Bid_id(Which is unique for every record) and Load_id(multiple entries) is my primary and sort key respectively.

How do I handle the Update of the Non-Key attribute of the table?

table.update_item(
            Key={
                'load_id': load_id,
                'bid_id' : bid_id
                },
            ConditionExpression=(
                        'load_id = :id'
                        
                ),
            
            UpdateExpression='SET #attr1 = :val1',
            ExpressionAttributeValues={':val1': status, ':id': id},
            ExpressionAttributeNames={'#attr1': 'status'},
            
            ReturnValues='UPDATED_NEW'
        )

Note: The value of Status and id is read from the event body.

Obviously, the above code only works when I need to change the status of the bid which got accepted to "Accept". I am thinking about how can I handle the "Rejection" status of other bids on the same load.

Could anyone help me out with this?

Answer 1

I do not believe there is a batch update option in DDB. You may have some luck with Transactions, which do allow updates but come with additional overhead. Alternatively, you may want to consider solving this problem with a sparse index.

For example, lets say your main table has the following bid information

and lets say you want to mark BID#1 as the accepted bid. Instead of introducing an attribute to define the accepted/rejected status, you could create a global secondary index on the accepted bid. For example

In this example, I created an additional attribute named GSIPK (you could name it anything, this is just an example). Logically, your index would look like this:

Notice that the index only contains the winning bid from LOAD#1. None of the other bids are in the index because none of the other bid items have a GSIPK attribute.

This may not satisfy all your access patterns around bids. However, it's a decent strategy to separate winning bids from rejected bids without having to do a bulk update of attributes.

If you did want to create an status attribute that you could set to the rejected/accepted status, you might consider setting the default status to rejected when inserting a bid. That way, you only have to update the single accepted bid once the bidding is done.