Clever Geek Handbook

Using the Meteor publish-with-relations package where every connection cannot use the _id field

I am working on a solution to a problem that is no different from the discussion presented on the following blog. It is the desire to publish two related datasets to Meteor with a "reactive join" on the server side.

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

Unfortunately for me, however, the linked collection I want to join will not be merged using the "_id" field, but using a different field. Usually in mongo and meteor I would create a "filter" block where I could ask this query. However, as far as I can tell in the PWR package, there is an implicit assumption about being attached to '_id'.

If you look at the example given on the publish-with-relations github page (see below), you can see that both posts and comments are linked to the "_id" field of Meteor.users. But what if we need to join the Meteor.users address field?

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

In the short term, I have refined my query upside down (as luckily I can use the _id field when joining back), but I suspect this will lead to an inefficient query as the datasets grow, so it will likely be able to join the intended direction.

The two collections we are merging can be thought of as a header / header topic entry and a conversation message collection (i.e. one entry in the collection for each message in the conversation).

The conversation topic in my solution uses the _id field to connect, the conversation messages have a "sessionKey" field that needs to be joined.

The next call works, but it's a message-to-conversation request, not the other way around, which would be more natural.

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


source to share


2 answers


Can you make a connection without the _id?

No, not with PWR. Joining with a foreign key that is another table / collection identifier is almost always associated with a relational data query. PWR makes this assumption to reduce the complexity of an already complex implementation.

How can posting be improved?

You don't really need a reactive join because one query doesn't depend on the result of the other. It would be if each conversation topic contained an array of conversation message IDs. Since both collections can be queried independently, you can return an array of cursors instead:



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

Notes

  • The sort in your post function is not useful if you are not using limit

    .

  • Be sure to use a forked version of PWR like this one , which includes Tom's memory leak fix.

  • Instead, conversationKey

    I would call it conversationTopicId

    clearer.

+1


source


I think it is now much easier to solve this with the reactive-publish package (I am one of the authors). Now you can make any request internally autorun

and then use the results of that to post the request you want to push to the client. I would write you some example code, but I don't quite understand what exactly you need. For example, you mentioned that you want to restrict topics, but you didn’t explain why they would be restricted if you provide requestedKey

, which is the document ID anyway? So, is there only one result available?



0


source






More articles:


All Articles