需要更新 GAE Java 中现有对象的主键
我正在使用 GAE Java 构建一个网络应用程序。我有一个类，它使用长 ID（由 appengine 生成）作为其主键。
我现在想创建一个新类，该类将成为这个原始类的父类（一对多关系），但是子类需要有一个“key”类型的主键，而不是我现在拥有的长 ID。
将现有持久实体的主键更改为“key”类型而不是 long 的最佳方法是什么？我是否应该创建一个主键类型为“key”的新类，并实例化并保留从旧对象复制字段值的新对象？或者我可以以某种方式更新现有的课程吗？
谢谢
I am building a web app using GAE Java. I have a class that uses a Long ID (generated by appengine) as its primary key.
I now want to create a new class that would be the parent class to this original class (a one to many relationship) however the child needs to have a primary key of type "key", not the Long ID I have now.
What is the best way to change the primary key to be type "key" instead of long for the existing persisted entities? Should I create a new class with primary key of type "key" and instantiate and persist new objects that copy the field values from the old ones? Or can I somehow just update the existing class?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
事实上，持久化实体的 Key 被认为是不可变的。毫无疑问，更改密钥将相当于更改所使用的实例。我建议您将初始对象链接到您创建的父对象的子对象。
In fact, the Key of a persisted Entity is considered to be immutable. Changing the key will, without a doubt, be equivalent to changing the used instance. What I suggest you is to link your initial object to a child of you created parent.
您可以将现有的长 ID 存储在父类的列表中：这将创建必要的一对多父子关系。
不过，您必须自己管理一致性（如果您的站点流量不是很高，这可能不会太困难），并且父类和子类不会位于同一实体组中（对事务的影响）。
更改密钥意味着更改实体本身（及其实体组）。
最终，适合您的解决方案将取决于您问题的具体情况。例如，现有数据是否已经很多？这是一个实时应用程序（即它是否已被使用）？
另一种解决方案可能是将您的应用程序迁移到不同的（更适合的）数据模型，并逐个帐户地执行此操作（通过在短时间内锁定帐户）。这样，只有少数人会受到更改的影响（如果他们在您迁移其帐户时碰巧访问了该应用程序），而不是整个应用程序都被关闭。
You could store the existing Long IDs in a list in the parent class: that would create the necessary one-to-many parent-child relationship.
You would have to manage consistency yourself though (which may not be too difficult if your site doesn't have very high traffic), and the parent and child classes would not be in the same entity group (implications for transactions).
Changing the key means changing the Entity itself (and also its entity group).
Ultimately, the solution that works for you will depend on the specifics of your problem. For example, is there already a lot of existing data? Is this a live application (i.e., is it already being used)?
Another solution could be to migrate your app over to a different (better suited) data model, and do so account-by-account (by locking out the account for a brief period of time). This way only a few individuals will be affected by the change (if they happen to access the app when you are migrating their account) rather than the whole app being down.