Question

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

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

不幸的是，对于我来说，我希望加入的相关集合不会使用＆＃34; _id＆＃34;字段，但使用另一个字段。通常在mongo和meteor中我会创建一个过滤器＆＃39;阻止我可以指定此查询。但是，据我所知，在PWR包中，有一个隐含的假设是加入＆＃39; _id＆＃39;。

如果您查看“发布与关系”中给出的示例＆＃39; github页面（见下文）你可以看到帖子和评论都加入了Meteor.users＆＃39; _id＆＃39;领域。但是，如果我们需要加入Meteor.users＆＃39;地址＆＃39;领域？

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

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

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

我的解决方案中的对话主题是使用_id字段加入，对话消息有一个＆＃34; conversationKey＆＃34;要加入的字段。

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

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 }
    },
  }]
});

Answer 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。
请务必使用像this one这样的分支版本的PWR，其中包括Tom的内存泄漏修复程序。
而不是conversationKey我会称之为conversationTopicId更清楚。

Answer 2

我认为使用reactive-publish包（我是作者之一）可以更容易地解决这个问题。您现在可以在autorun内进行任何查询，然后使用其结果发布要推送到客户端的查询。我会给你写一个示例代码，但我真的不明白你到底需要什么。例如，您提到您希望限制主题，但是如果您提供的requestedKey是文档的ID，则无法解释为什么它们会受到限制？那么只有一个结果可用吗？

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

2 个答案:

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

如何改进此发布？

注释