Achieve multiple item transactional support

[xavicosta]

I would like to achieve multiple item transactional support with the Object Persistence Model AWS .NET SDK.

[klaytaybai]

Thanks for the feedback. We'll have to consider the implementation details.

[xavicosta]

What's the outcome on this? Has multiple item transactional support been added to the Object Persistence Model?

[Mikkel-Gram]

It's not there in the latest nuget version as far as i can see

[scottjbaldwin]

Any update on the status of this issue? It would come in really handy for my current project.

[marcushuynh]

Another follow-up comment. Do we have any update on this one?

[dtabuenc]

How hard can this possibly be? Transaction support is already in the low level library, I would assume the high level libraries are just handling type serialization and such... so how hard is it to add the transactional version of the batching methods?

[dtabuenc]

For anyone looking for a workaround, you can combine the low-level api with high-level api serialization by doing something like:

    var dynamoDbClient = new AmazonDynamoDBClient();
    var dynamoDbContext = new DynamoDBContext(dynamoDbClient);
    var item1 = new MySampleItem();
    var item2 = new MySampleItem();
    await dynamoDbClient.TransactWriteItemsAsync(new TransactWriteItemsRequest()
    {
      TransactItems = new List<TransactWriteItem>
      {
        new TransactWriteItem()
        {
          Put = new Put()
          {
            Item = dynamoDbContext.ToDocument(item1).ToAttributeMap(),
            TableName = dynamoDbContext.GetTargetTable<MySampleItem>().TableName
          },
        },
        new TransactWriteItem()
        {
          Put = new Put()
          {
            Item = dynamoDbContext.ToDocument(item2).ToAttributeMap(),
            TableName = dynamoDbContext.GetTargetTable<MySampleItem>().TableName
          }
        },
      }
    });

[bmcclory]

For anyone looking for a workaround...

FYI not a complete workaround, because (e.g.) PUT requests can also include condition expressions in the transaction write item. Unfortunately, the methods for converting (DocumentModel) Expression types to the low-level AttributeValue-based types are all internal:

aws-sdk-net/sdk/src/Services/DynamoDBv2/Custom/DocumentModel/Expression.cs

Line 142 in 6ac6949

internal static Dictionary<string, AttributeValue> ConvertToAttributeValues(

Even just converting a single DynamoDBEntry to an AttributeValue is an internal operation. I.e. these higher-level abstractions aren't very extensible or usable "al a carte", unfortunately.

I noticed that ExpressionAttributeValues are Dictionary<string, DynamoDBEntry>, and so is a Document, so maybe you could cheat here convert those attribute values to a temporary Document, and then convert that ToAttributeMap? But I'm uncertain about the implications there -- workarounds upon workarounds.

DynamoDB has supported transactions for years. It's a shame they aren't well supported in the .NET SDK.

[dtabuenc]

FYI not a complete workaround, because (e.g.) PUT requests can also include condition expressions in the transaction write item.

Correct, but at that point writing an expression using low-level attribute names/values/expression syntax, while not ideal, is also not too difficult (not nearly as difficult as trying to serialize/deserialize a bunch of types).

The entire high-level dotnet code seems pretty poorly though-out and a bit over-engineered, and it's baffling that something like transactions which is easily supported by the low level api has no support in either of the high-level offerings. I've come very close to just writing a better high-level api to use out our company, especially since the amazon-provided high-level apis don't handle single-table-schema type layouts very well.

[bmcclory]

I've come very close to just writing a better high-level api to use out our company, especially since the amazon-provided high-level apis don't handle single-table-schema type layouts very well.

Preach! Exact same situation here, really trying to avoid implementing our own SDK around low-level API. But the limitations of these higher-level SDK APIs are really dragging us down.

I'll also point out: The somewhat convenient DynamoDbVersionAttribute isn't usable with your workaround; the auto-incrementing behavior only occurs when you call DynamoDbContext.Save(). (And besides, I think those version checks cashe out as a legacy "ExpectedValues" parameter on the UpdateItem request, which would require some tricky conversion into a Condition expression on a transact write item....)

[ashishdhingra]

#2534 was manually merged and released today as version 3.7.103 of AWSSDK.DynamoDBv2.

• 33de1ae through c98aeb4

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

[bmcclory]

@RenesansJG

First, thanks for the awesome PR this is a very welcome enhancement to the SDK!

I've been exploring the new APIs, and I'm trying to figure out a way where I could do a "hybrid" write transaction that has some items built using the high-level Object model and others with the Document model.

It doesn't seem like there's any technical barrier there -- the DocumentTransactWrite and (object) TransactWrite could probably have a unified type hierarchy. But as things currently stand, it seems impossible, unless I'm missing something.

The motivation here is that transactions (by their nature) involve a mix of items, and some of them would benefit from the simpler programming model offered by Object model while others require the more fine-grained Document model. As things currently stand, it seems that if any item within the transaction demands Document model, the entire transaction must drop down to that level, and you lose high-level benefits like the [DynamoDBVersion] attribute and have to hand-roll that behavior.