这是一个固有的问题数据库模式。对架构的一些更改将使您的任务更轻松。

不要在post或comment对象中存储注释id数组。当数组变得非常大,或者许多客户机需要同时更新父对象时,这将导致问题。

相反,在每个comment对象中,存储它所属的post的id,以及它所响应的comment的id(如果有的话)。然后,要加载帖子的评论,请搜索属于该帖子的每个评论并执行 topological sort 在生成的对象上。

与您所描述的模式相比,这个模式有许多主要的优点——该模式与传统的关系数据库兼容,post的所有注释都可以在一个查询中检索,新的注释可以用一个insert查询添加。

不需要。要创建拉请求,用户需要能够查看原始存储库,以创建请求repo所有者合并的分支。

(换句话说:您不能建议对无法查看的代码进行更改!)