Add subscription name to query result

In a situation where more than one subscription might be in effect, I’d like to make sure that I only query data from a certain subscription, not among all data that might be currently available for that particular collection and user.

So I thought I’d do something like
SELECT field1, field2, "value" as "myXtraField" FROM myTable;
but of course in MongoDb, in my publish function.

That way I could do a simple
myCollection.find({myXtraField: "value"})
without the risk that other subscriptions come into play.

I’d like to do that without iterating through the entire query result in the publication.

Is there a good way to achieve this?

Just replicate the query on the client side.

If one subscription is

return Whatever.find({ count: { $gt: 10 } })

and another subscription is

return Whatever.find({ count: {$lt: 10 } });

Then you can query a specific subscription by repeating that query on the client.

Whatever.find({ count: { $gt: 10 } });
# => Would only return results from greaterThan10 subscription

The data from both subscriptions would be available to my client side find().

Correct. You would filter the result in your client side find.

Yes, I could replicate the query, but I’d prefer not to. Partly because of efficiency and partly because the duplicated code would have to be kept manually in sync until forever.

You don’t duplicate the code. You would write the query once, and export it.

// whatever.js

export const someQuery = {
  count: {
    $gt: 10

Meteor.publish('greaterThan10', function() {
  return Whatever.find(someQuery);
// SomeComponent.js
import { someQuery } from '/imports/api/whatever.js'


Yes, that is true and it would work. Still, I’d have to execute a very heavy query twice

Have you looked at percolate:find-from-publication?

Oh, I just realized why I got into this situation to begin with: I cannot use $text client side. So the duplicate query will not work.

maybe that could work, but it looks like a pretty… strange workaround.
If I don’t find another way, I’ll try it though.

Does the data need to be reactive?

If not, just return the data from a method

It needs to be reactive, yes.

I find it strange that there seem to be no simple way of doing something that is pretty standard in SQL.