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

Question

上下文

我来自对 SQL事务的基本理解，其流程如下：

1. BEGIN SQL事务。为了论证，我们假设我们正在使用Read Committed隔离级别。
2. 在SQL事务中运行任意数量的INSERT，UPDATE和DELETE语句。其中没有一个在外面可见 由于我们在这个假设中使用的“Read Committed”隔离级别，该事务（尚未）。
3. COMMIT该交易，将我们的INSERT，UPDATE和DElETE发送给其他人。或者ROLLBACK更改。无论哪种方式，交易都不再相关。

现在，我正在尝试使用对SQL事务的这种理解来引导我对 Google数据存储区事务的理解，并且遇到了麻烦。 Datastore REST API v1 documentation确实有beginTransaction，commit和rollback个端点，因此乍一看它看起来像是SQL事务系统的简单模拟。但是，数据存储区commit端点也可用作修改数据存储区中数据的（显然唯一的）机制。事实上，一个端点似乎对两个（在我看来）不同但至关重要的操作负责，这对我造成了混乱。

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

• 也许Datastore documentation中有一些显而易见的东西我设法忽略了 - 嗯，这对我来说并不明显¯\ _（ツ）_ /¯
• 也许有一个虚构的'mutate'数据存储端点没有记录 - 不太可能，但我希望
• 也许有一种方法可以使用commit端点的变异功能，而无需实际提交事务 - 提交端点有一个mode参数，其值为TRANSACTIONAL和NON_TRANSACTIONAL（被描述为“突变可能不适用于所有或不适用”）。也许NON_TRANSACTIONAL选项的命名/描述很差，可用于在事务中提交突变而不立即提交它们（但是当事务最终提交/回滚时它们都将被提交/回滚） 。我目前正在调查此选项
• 也许Datastore不支持提交突变而不提交它们 - 我真的希望不是这样的
• 也许数据存储区事务与SQL事务的行为有很大不同 - 很可能
• 也许我（上述）对SQL事务的理解不正确 - 那会非常尴尬

实际问题

如果数据存储区commit端点混淆了突变的提交和这些突变的提交，我如何通过REST API提交对数据存储区的修改而不立即进行这些修改？

Answer 1

NON_TRANSACTIONAL 表示您要应用的更改将以未定义的顺序应用，并且此类提交的结果将通过相对未定义的顺序以未定义的顺序显示。我知道，太多未定义。不久之后，他们表现得像独立的独立突变一样。

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

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

文档说：

  

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

     

  
• insert后插入
  
• 更新后插入
  
• upsert，然后插入
  
• 删除后跟更新
  

此行表示

  

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

突变累加器就在你身边。

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

  

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

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