Objectify 中的延迟保存是否适用于每个 Java 实体或每个 Google Cloud Datastore 实体？答案

【问题标题】：Does deferred save in Objectify apply per Java entity or per Google Cloud Datastore entity?Objectify 中的延迟保存是否适用于每个 Java 实体或每个 Google Cloud Datastore 实体？
【发布时间】：2018-12-20 02:37:16
【问题描述】：

我们的应用逻辑有多个层次。每次调用保存时，域层上的实体都会映射到数据库实体。

例如：

class Sample(); // the domain entity

@Entity("Sample")
@Cache
class DatabaseSample; // the database entity

假设域实体被修改并调用了保存，这会将所有属性映射到一个新的数据库实体，然后将其保存延迟。

假设同一个域实体再次修改并再次保存，这将再次将所有属性映射到新的数据库实体并调用延迟保存。

这两个独立的 Google Cloud Datastore 实体是否会相互竞争，例如较新的保存会完全覆盖较旧的保存，还是会在请求期间客观化收集修改后的键值对并在请求结束时保存合并的实体？

【问题讨论】：

根据documentation，在save() 和delete() 操作都为同一实体延迟的情况下，最后一个操作获胜。但是，如果您将两个域实体映射到不同的数据库实体，则不会有任何覆盖。我理解你的应用逻辑吗？

标签： google-app-engine objectify

【解决方案1】：

我不太明白这个问题，但我会尝试为您提供一些可能会有所帮助的背景信息。

如果您推迟保存实体 POJO，它只会在会话中将其标记为“保存此东西”。当会话关闭（事务结束）时，任何标记为延迟保存（或删除）的内容都会被保存。

只有在保存到数据存储的那一刻，POJO 才会映射到低级实体。您可以推迟保存同一个对象无数次而没有实际效果。事实上，这是核心用例 - 您可能有一个方法设置更改一些数据并想要保存，以及一些其他方法更改一些数据并想要保存......通过使用延迟保存，您避免了单独的真实保存到数据存储区。

如果你想在推迟保存后做一些非常疯狂的事情，比如更改@Id...不要。我真的不知道那会做什么，但你可能不会喜欢它:-)

【讨论】：