如何在Google App Engine中创建有几个死者/祖先的API方法 [英] How to create API methods in Google App Engine that have several decedents/ancestors

问题描述

我很难理解如何与几个死者构建一棵祖先树。假设我有这样的模型（每个实体都有一个 Long id ）：

  User 
 -Post 
 -comment 
  

其中 Comment 是 User 的孙子。

真正烦人的是插入一个 Comment 我需要生成发布。并且要生成 Post的键我还需要知道 User 的I​​D：

 键< Post> postKey = Key.create（Key.create（User.class，userId），Post.class，postId）; 
  

这对我来说是一个问题，因为当试图向数据存储中插入注释时，我还需要传递在userId和postId中只是为了生成 Post 的键。



同样，尝试获得一个Post是烦人的，因为我需要传入userId和postId来生成密钥。

我正在寻找一种更好的方式来构建我的模型和API方法，而无需将所有这些祖先ID传递到我的方法。我正在考虑在每个Post和Comment实体中存储websafeKey作为这样的属性：

 字符串websafeKey = Key.create（Key .create（User.class，userId），Post.class，postId）.getString（）; 
钥匙< Post> key = Key.create（websafeKey）; 
  

然后我可以找到每个帖子和评论（以及这些实体的其他子项）的关键字）在实体中。那么大概我不必将所有这些祖先ID始终传递给我的API方法。

不知道这是否是一个好主意。根据所提供的信息，您有两种选择：

$ b $ b
• 传递完整的密钥并围绕它设计API
  
• 解耦您的实体祖先关系，以便没有实体拥有父项

注意：完全写完这些之后，我意识到终端API看起来也是一样：

  GET / user / {key}  - 获取用户信息
 POST / user / {key} / post /  - 创建信息
 GET / post / {key}  - 获取信息
 POST / post / {key} / comment /  - 创建注释
 GET / comment / {key} 
  

全键

在这种情况下，{key}是网络安全密钥。

优点：$ b​​
$ b

• 您可以维护事务和一致性控制


• 允许您稍后更改父实体关系，而无需迁移旧数据并破坏旧链接（以我的经验，这是一次巨大的胜利）。
  
• 允许您混合种类例如：有Post类型和Post2类型或ImagePost类型 - 对于多态性或用于中断迁移很有用）
  
  $ b $

  将实体分离为祖先

  
  
  

  在这种情况下{key}是id，并且没有实体层次结构
  
  

  Dis / Advantages：
  
  

  
  
  • 简单
  
  
  • 您需要根据网址推断种类
    
  • 如果您需要引入事务组，则$ b
  • 为用户列出帖子或为帖子发表评论总是最终的
  
  
  • 无迁移路径
  ul>
  
  像这样构建API的整体好处：
  
  
  
  
  • consis的内部耦合tency和交易性不通过API暴露
    
  • 符合restful API作为资源概念
  
  
  • 支持任一模式
  
  
  
  
  

  根据我的经验，您绝对应该做第一个选择，您可能会让您的数据模型出错几次，并且能够更改/迁移它是绝对的胜利。 p>
  

  I am having trouble understanding how to structure an ancestor tree with several decedents. Suppose I have a model like this (every Entity has a Long id):

  User
      -Post
          -Comment
  

  Where the Comment is the grandchild of the User.

  What is really annoying is to insert a Comment I need to generate the Key of the Post. And to generate the Key of the Post I also need to know the ID of the User:

  Key<Post> postKey = Key.create(Key.create(User.class, userId), Post.class, postId);
  

  This is a problem for me because when trying to insert a Comment into the datastore I need to also pass in the userId and postId just to generate the key of the Post.

  Similarly, it is annoying to try and get a one Post because I need to pass in both the userId and postId to generate the Key.

  I am looking for a better way to structure my model and API methods without having to pass in all those ancestor IDs to my methods. I was considering storing the websafeKey in every Post and Comment entity as a property like this:

  String websafeKey = Key.create(Key.create(User.class, userId), Post.class, postId).getString();
  Key<Post> key = Key.create(websafeKey);
  

  Then I could the key to every Post and Comment (and other children of these Entities)) right there in the Entity. Then presumably I wouldn't have to pass in all those ancestor IDs in to my API methods all the time.

  Not sure if that is a good idea though.

  解决方案

  Based on the info provided you have two options:

  • Pass full keys around and design your API around that
  • decouple your entities ancestor relationships, so that no entity has a parent

  Note: after writing this all out, I realized the end API looks the same really either way:

  GET /user/{key} - get user info
  POST /user/{key}/post/ - create post 
  GET /post/{key} - get post
  POST /post/{key}/comment/ - create comment
  GET /comment/{key} 
  

  Full keys

  In this case, {key} is the websafe key.

  Advantages:

  • you can maintain transactional and consistency control
  • allows you to change parent entity relationship later without migrating old data and breaking old links (in my experience this is a massive win)
  • Allows you to mix kinds (e.g. Have a Post kind and a Post2 kind, or an ImagePost kind - useful for polymorphism or for breaking migrations)

  Decouple entities as ancestors

  In this case {key} is the id, and there is no entity hierarchy

  Dis/Advantages:

  • Simplicity
  • You need to infer the kind based on the URL
  • listing posts for a user or comments for a post would always be eventual
  • no migration path if you need to introduce transaction groups
  Overall benefits of structuring your API like this:
  • internal coupling for consistency and transactionality not exposed through API
  • aligns with restful API as resource concept
  • supports either model

  In my experience you should absolutely do the first option, you will probably get your data model wrong a few times, and being able to change/migrate it is an absolute win.

  这篇关于如何在Google App Engine中创建有几个死者/祖先的API方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！