使用 Meteor publish-with-relations 包，其中每个连接都不能使用 _id 字段答案

【问题标题】：Using Meteor publish-with-relations package where each join cannot use the _id field使用 Meteor publish-with-relations 包，其中每个连接都不能使用 _id 字段
【发布时间】：2015-01-22 06:16:04
【问题描述】：

我正在努力解决一个与以下博客文章中的讨论没有什么不同的问题。这是希望在 Meteor 中发布两个相关的数据集，并在服务器端使用“反应式连接”。

https://www.discovermeteor.com/blog/reactive-joins-in-meteor/

不幸的是，我希望加入的相关集合不会使用“_id”字段加入，而是使用另一个字段加入。通常在 mongo 和流星中，我会创建一个“过滤器”块，我可以在其中指定此查询。但是，据我所知，在 PWR 包中，有一个隐含的假设要加入“_id”。

如果您查看 'publish-with-relations' github 页面上给出的示例（见下文），您可以看到帖子和 cmets 都已加入 Meteor.users '_id' 字段。但是如果我们需要加入 Meteor.users 的“地址”字段呢？

https://github.com/svasva/meteor-publish-with-relations

在短期内，我已将我的查询指定为“颠倒”（幸运的是，我可以在进行反向连接时使用 _id 字段），但我怀疑随着数据集的增长，这将导致查询效率低下，所以宁愿能够按照计划的方向加入。

我们加入的两个集合可以被认为是一个对话主题/标题记录和一个对话消息集合（即集合中的一个条目对应于对话中的每条消息）。

我的解决方案中的对话主题是使用 _id 字段加入，对话消息有一个“conversationKey”字段可以加入。

以下调用有效，但这是从消息到对话的查询，而不是反之亦然，这会更自然。

Meteor.publishWithRelations({
  handle: this,
  collection: conversationMessages,
  filter: { "conversationKey" : requestedKey },
  options : {sort: {msgTime: -1}},
  mappings: [{
    //reverse: true,
    key: 'conversationKey',
    collection: conversationTopics,
    filter: { startTime: { $gt : (new Date().getTime() - aLongTimeAgo ) }  },
    options: {
      sort: { createdAt: -1 }
    },
  }]
});

【问题讨论】：

请在您的问题中添加以下内容：您希望加入的集合的相关架构信息、您希望如何加入它们以及您目前编写的代码。
我现在已经做到了。然而，更普遍的问题是，如果连接不在任一侧的“_id”字段上，是否可以这样做。

标签： javascript meteor

【解决方案1】：

你可以在没有 _id 的情况下进行连接吗？

不，不是 PWR。与作为另一个表/集合中的 id 的外键连接几乎总是如何查询关系数据。 PWR 做出这样的假设是为了降低已经很棘手的实现的复杂性。

如何改进此发布？

您实际上并不需要反应式联接，因为一个查询不依赖于另一个查询的结果。如果每个对话主题都包含一组对话消息 id，就会出现这种情况。因为两个集合都可以独立查询，所以可以返回一个游标数组：

Meteor.publish('conversations', function(requestedKey) {
  check(requestedKey, String);
  var aLongTimeAgo = 864000000;
  var filter = {startTime: {$gt: new Date().getTime() - aLongTimeAgo}};

  return [
    conversationMessages.find({conversationKey: requestedKey}),
    conversationTopics.find(requestedKey, {filter: filter})
  ];
});

注意事项

在您的发布函数isn't useful 中排序，除非您使用的是limit。
请务必使用 PWR 的分支版本，例如 this one，其中包含 Tom 的内存泄漏修复。
为了更清楚，我将其称为conversationTopicId，而不是conversationKey。

【讨论】：

感谢您的回复。我将切换到 Tom 的 PWR 前叉。在我的情况下，我确实需要使用连接，因为我们确实想限制结果（有限的会话主题而不是会话消息）。
是的，这更有意义；限制是一条关键信息。因此，考虑到这一点，这个问题的可接受答案是什么样的？我应该反转原始查询吗？

【解决方案2】：

我认为使用reactive-publish 包（我是作者之一）现在可以更轻松地解决这个问题。您现在可以在 autorun 中进行任何查询，然后使用查询结果发布您想要推送到客户端的查询。我会给你写一个示例代码，但我不太明白你到底需要什么。例如，您提到您想限制主题，但您没有解释如果您提供requestedKey（无论如何都是文档的ID）为什么会受到限制？所以只有一个结果可用？

【讨论】：