何时禁用 aws Amplify 或 AppSync 冲突解决
我注意到在新的 Amplify Graphql 转换器 v2 中，默认情况下为所有表启用 AppSync 冲突解决 (https://docs.aws.amazon.com/appsync/latest/devguide/conflict-detection-and-sync.html），我想知道如果我禁用冲突解决是否会带来任何危害我的API？
我正在构建一个类似 yelp 的评级应用程序，如果两个客户端尝试改变同一个对象，我认为让它们同时改变就可以了，稍后的请求会覆盖前一个请求。所以我不太明白这个冲突解决有什么用？
我觉得在修改对象时需要传入 _version 字段，删除时不会立即删除，而是将 _deleted 字段设置为，这确实很不方便true 并计划在 ttl 时间后删除
非常感谢！
专业提示：要禁用 amplify 中的冲突解决程序，请运行 amplify update api，系统将提示您选择禁用冲突解决程序
I noticed in the new Amplify Graphql transformer v2, AppSync Conflict Resolution is enabled for all tables by default (https://docs.aws.amazon.com/appsync/latest/devguide/conflict-detection-and-sync.html), I wonder if it will bring any harm if I disable conflict resolution for my API?
I'm building a yelp like rating app, and if two clients try to mutate the same object, I think it's fine just let them mutate concurrently and the request comes later overrides the previous one. So I don't really understand what this conflict resolution is useful for?
I feel it's really inconvenient that I need to pass in a _version field when mutating an object and when deleting, it will not delete immediately, instead it will have _deleted field set to true and schedule to delete after ttl time
Thanks very much!
Pro tip: to disable conflict resolver in amplify, run amplify update api, and you will be prompt to a choice to disable conflict resolver
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
版本化数据源
AWS AppSync 目前支持 DynamoDB 数据源的版本控制。冲突检测、冲突解决和同步操作需要版本化数据源。当您对数据源启用版本控制时，AWS AppSync 将自动：
使用对象版本控制元数据增强项目。
将对具有 AWS AppSync 突变的项目所做的更改记录到增量表中。
使用“逻辑删除”在基表中维护已删除的项目一段可配置的时间。
版本化数据源配置
当您在 DynamoDB 数据源上启用版本控制时，您可以指定以下字段：
BaseTableTTL
在基表中保留已删除项目的分钟数，并带有“逻辑删除”（指示该项目已被删除的元数据字段）。如果您希望在删除项目时立即将其删除，则可以将此值设置为 0。此字段是必需的。
Delta同步表名称
存储对具有 AWS AppSync 突变的项目所做的更改的表的名称。此字段是必需的。
DeltaSyncTableTTL
在 Delta 表中保留项目的分钟数。此字段是必需的。
增量同步表
AWS AppSync 目前支持使用 PutItem、UpdateItem 和 DeleteItem DynamoDB 操作进行变更的增量同步日志记录。
当 AWS AppSync 突变更改版本化数据源中的项目时，该更改的记录将存储在针对增量更新进行优化的 Delta 表中。您可以选择对其他版本化数据源使用不同的 Delta 表（例如，每种类型一个、每个域区域一个），或者为您的 API 使用单个 Delta 表。 AWS AppSync 建议不要对多个 API 使用单个增量表，以避免主键冲突。
该表所需的架构如下：
ds_pk
用作分区键的字符串值。它是通过连接基础数据源名称和 ISO8601 格式的更改发生日期来构建的。 （例如评论：2019-01-01）
ds_sk
用作排序键的字符串值。它是通过连接 IS08601 格式的更改发生时间、项目的主键和项目的版本来构造的。这些字段的组合保证了 Delta 表中每个条目的唯一性（例如，对于时间 09:30:00、ID 1a 和版本 2，这将是 09:30:00:1a:2）
_ttl
一个数值，用于存储应从 Delta 表中删除项目的时间戳（以纪元秒为单位）。该值是通过将数据源上配置的 DeltaSyncTableTTL 值添加到发生更改的时刻来确定的。该字段应配置为 DynamoDB TTL 属性。
配置用于基表的 IAM 角色还必须包含对增量表进行操作的权限。在此示例中，显示了名为 Comments 的基表和名为 ChangeLog 的增量表的权限策略：
Versioned Data Sources
AWS AppSync currently supports versioning on DynamoDB data sources. Conflict Detection, Conflict Resolution, and Sync operations require a Versioned data source. When you enable versioning on a data source, AWS AppSync will automatically:
Enhance items with object versioning metadata.
Record changes made to items with AWS AppSync mutations to a Delta table.
Maintain deleted items in the Base table with a “tombstone” for a configurable amount of time.
Versioned Data Source Configuration
When you enable versioning on a DynamoDB data source, you specify the following fields:
BaseTableTTL
The number of minutes to retain deleted items in the Base table with a “tombstone” - a metadata field indicating that the item has been deleted. You can set this value to 0 if you want items to be removed immediately when they are deleted. This field is required.
DeltaSyncTableName
The name of the table where changes made to items with AWS AppSync mutations are stored. This field is required.
DeltaSyncTableTTL
The number of minutes to retain items in the Delta table. This field is required.
Delta Sync Table
AWS AppSync currently supports Delta Sync Logging for mutations using PutItem, UpdateItem, and DeleteItem DynamoDB operations.
When an AWS AppSync mutation changes an item in a versioned data source, a record of that change will be stored in a Delta table that is optimized for incremental updates. You can choose to use different Delta tables (e.g. one per type, one per domain area) for other versioned data sources or a single Delta table for your API. AWS AppSync recommends against using a single Delta table for multiple APIs to avoid the collision of primary keys.
The schema required for this table is as follows:
ds_pk
A string value that is used as the partition key. It is constructed by concatenating the Base data source name and the ISO8601 format of the date the change occurred. (e.g. Comments:2019-01-01)
ds_sk
A string value that is used as the sort key. It is constructed by concatenating the IS08601 format of the time the change occurred, the primary key of the item, and the version of the item. The combination of these fields guarantees uniqueness for every entry in the Delta table (e.g. for a time of 09:30:00 and an ID of 1a and version of 2, this would be 09:30:00:1a:2)
_ttl
A numeric value that stores the timestamp, in epoch seconds, when an item should be removed from the Delta table. This value is determined by adding the DeltaSyncTableTTL value configured on the data source to the moment when the change occurred. This field should be configured as the DynamoDB TTL Attribute.
The IAM role configured for use with the Base table must also contain permission to operate on the Delta table. In this example, the permissions policy for a Base table called Comments and a Delta table called ChangeLog is displayed: