You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We'd like to be able to decide to skip transactions in the log based on the transaction types we care about for a given query.
We'd like to ensure that we will never need to load a transaction from S3 to do this, and it can be included in a filter for DynamoDB.
Analysis
We can ensure that a transaction record in DynamoDB or S3 always corresponds to a single type of transaction, even if we combine multiple transactions together.
In the DynamoDB item we can separate the transaction type from the fact of whether it's held in the DynamoDB item or in S3.
This will need to be done in DynamoDBTransactionLogStore.
Note that if we combine transactions into one in an invocation of the state store committer lambda (in #2992), but we never combine transactions of different types, that means instead of one transaction added to the log per lambda invocation, we would have as many as there are different types of transaction. This should still allow us to get the throughput we need, and we could change our minds about it later.
The text was updated successfully, but these errors were encountered:
Background
Split from:
Related to:
Description
We'd like to be able to decide to skip transactions in the log based on the transaction types we care about for a given query.
We'd like to ensure that we will never need to load a transaction from S3 to do this, and it can be included in a filter for DynamoDB.
Analysis
We can ensure that a transaction record in DynamoDB or S3 always corresponds to a single type of transaction, even if we combine multiple transactions together.
In the DynamoDB item we can separate the transaction type from the fact of whether it's held in the DynamoDB item or in S3.
This will need to be done in DynamoDBTransactionLogStore.
Note that if we combine transactions into one in an invocation of the state store committer lambda (in #2992), but we never combine transactions of different types, that means instead of one transaction added to the log per lambda invocation, we would have as many as there are different types of transaction. This should still allow us to get the throughput we need, and we could change our minds about it later.
The text was updated successfully, but these errors were encountered: