使用 HTTP API 写入数据存储区而不提交事务答案

【问题标题】：Write to Datastore using HTTP API without committing transaction使用 HTTP API 写入数据存储区而不提交事务
【发布时间】：2018-05-10 05:11:56
【问题描述】：

上下文

我对 SQL 事务 有基本的了解，其流程类似于：

BEGIN 一个 SQL 事务。为了论证，假设我们使用Read Committed 隔离级别。
在 SQL 事务中运行任意数量的INSERT、UPDATE 和DELETE 语句。外面都看不到由于我们在这个假设中使用的“已提交读”隔离级别，事务（尚未）。
COMMIT 交易，将我们的 INSERTs、UPDATEs 和 DElETEs 发送给其他人。或者ROLLBACK 更改。无论哪种方式，交易都不再相关。

现在我正在尝试利用对 SQL 事务的理解来引导我对 Google 数据存储事务 的理解，但遇到了困难。 Datastore REST API v1 documentation 确实有 beginTransaction、commit 和 rollback 端点，所以乍一看，它看起来像是 SQL 事务系统的简单模拟。但是，Datastore commit 端点也可以作为我们（显然只是）修改 Datastore 中数据的机制。事实上，一个端点似乎负责两个（在我看来）不同但至关重要的操作，这让我感到困惑。

可能性（我已经探索过）：

也许Datastore documentation 中有一些明显的东西我已经设法忽略了 - 嗯，这对我来说并不明显 ¯\_(ツ)_/¯
也许有一个未记录的幻影“变异”数据存储端点 - 不太可能，但我希望
也许有一种方法可以在不实际提交事务的情况下使用commit 端点的变异功能 - 提交端点有一个mode 参数，其值为TRANSACTIONAL 和NON_TRANSACTIONAL（其中被描述为“突变可能不适用于全部或不适用”）。也许NON_TRANSACTIONAL 选项只是名称/描述不佳，可用于在事务中提交突变而不立即提交它们（但是当事务最终提交/回滚时，它们都将被提交/回滚）。我目前正在研究这个选项
也许 Datastore 不支持在不提交的情况下提交突变 - 我真的希望不是这种情况
也许数据存储事务的行为与 SQL 事务有很大不同 - 很有可能
也许我（上述）对 SQL 事务的理解不正确 - 那会非常尴尬

实际问题

如果数据存储区commit 端点将突变的提交和这些突变的提交混为一谈，我如何通过 REST API 向数据存储区提交修改而不立即提交这些修改？

【问题讨论】：

亲爱的 Jaysen，我在尝试实施 Datastore 事务时遇到了确切的问题。也许自从你发布这个问题以来，你比我更了解这个问题。如果不通过在提交中直接暗示事务的结束，是否真的不可能以事务方式创建、更新（或删除）？您是否找到了一种无需提交即可执行多个事务性创建、更新和删除的方法？
@GlobalRationality 凭记忆，我想我从来没有找到一个简洁的方法。我想我只需要围绕 API 的这一方面进行架构设计

标签： transactions google-cloud-datastore

【解决方案1】：

NON_TRANSACTIONAL 表示您要应用的更改将以未定义的顺序应用，并且此类提交的结果将以未定义的顺序通过相对未定义的顺序可见。太多未定义，我知道。简而言之，它们的行为就像独立的独立突变一样。

TRANSACTIONAL 与 SQL 世界中的含义相同。在突变体中，您将传递您想要完成的所有突变，并且所有突变都会成功或不成功。这就是ACID标准规定的所有差异+并发控制。

如果您谈论一些事务的累积模型，当您可以开始此类事务时，将一些更改发送到数据存储（累积），然后将此类快照应用于数据存储，那么这是不可能的。

文档说：

当模式为 TRANSACTIONAL 时，会按顺序应用影响单个实体的突变。在单个 projects.commit 请求中不允许出现以下影响单个实体的突变序列：

插入后插入

更新后插入

先插入后插入

删除后更新

这条线表示

影响单个实体的突变按顺序应用

突变累加器就在你身边。

数据存储中的事务是短暂的。

事务的最长持续时间为 60 秒，30 秒后有 10 秒的空闲过期时间。

链接到数据存储中的事务描述。 https://cloud.google.com/datastore/docs/concepts/transactions

【讨论】：