publish.once: changed message sent instead of added

[harry-73]

Hi,

I have a publication :

Meteor.publish.once('tests', function () {
 
  return Tests.find(
    {
      isPrivate: true,
      ownerId: this.userId
    }
  );
});

On client side, i have :

Meteor.subscribe('tests')

At the beginning, I have one document matching the filter. So one document is added to minimongo.

Via a moethod, I update another document by setting isPrivate = true

From the server, I receive the message changed with the update field (isPrivate). I was expected to receive an added message with the complete document

[jamauro]

How and where are you updating the other document?

[harry-73]

Inside the application by a method with updateAsync.

in mongo.js file in Mongo.Collection.prototype.updateAsync = async function (, if I remove the projection argument for findOneAndUpdate, it is still a changed message sent but the all document is present and it added to minimongo

[jamauro]

How is the method invoked originally from a user's perspective? What is the scenario? e.g. User A does this, then they do that...

[harry-73]

the user goes the private objects list (subscribe), The user searchs for non private objects, select one, put it as private (method call) . The user returns automatically to the private objects list, the modified object must be present.

FYI: cache is enabled

[jamauro]

How are the non-private objects sent to the client?

[harry-73]

If you are talking when the user searchs, it is via a simple method.

[jamauro]

Ok I see. I think if you published those non-private documents with a .once, then it should just work. With your current setup, it sounds like the non-private document is neither in-memory on the server nor in minimongo.

[harry-73]

I think so, but I would like to prefer to avoid it. The number of non-private documents is huge.

I was expected when you update a document not already part of the publication, a added message with the all document would be sent if the document now matches the publication.

[jamauro]

Hmm I'm not sure how using .once would differ from your simple method in this scenario. After all .once is using a method under the hood so the data is being retrieved via a method either way and sent to the client.

I was expected when you update a document not already part of the publication, an added message with the all document would be sent if the document now matches the publication.

This can only work if the server is tracking the documents, i.e. has them in memory. This is what you get with meteor's standard Meteor.publish

[harry-73]

Hmm I'm not sure how using .once would differ from your simple method in this scenario. After all .once is using a method under the hood so the data is being retrieved via a method either way and sent to the client.

OK. I see. You were talking to replace my search method by a .once. Got it

This can only work if the server is tracking the documents, i.e. has them in memory. This is what you get with meteor's standard Meteor.publish

OK. .once will track the documents that match the publication at the time of the subscription. So (subcription still active):

• update on them will work,
• insert a new document will always sent a added message even if it does not match the filter of the publication
• update a document that does not match the filter of the publication will not work as it will send changed message with the only modified fields.

Correct ?

[harry-73]

Are my assumptions correct?

[jamauro]

Correct on the first two.

I'm not entirely sure I understand what you mean by "will not work" here:

update a document that does not match the filter of the publication will not work

The document will be updated and the changes will be sent back to the client which will be reflected in the UI depending on how you've set that up.

[harry-73]

Thanks.

For example, I have the following document in tests collection:

{
   _id: "xEXmYQABSbi79rLWS",
   ownerId: "rZd7ERscaQEF9rLeF",
   title: "Test",
   count: 10
},
{
   _id: "ack5L5ivM5ACBeNpK",
  ownerId: "pF5rs3fR7qZF9rd7f",
   title: "Test1",
   count: 5
},

and a .once publication:

Meteor.publish.once('tests', function (selectedCount) {
  check(id, Number);
 
  return Meteor.users.find({ ownerId: this.userId, count: {$gt: selectedCount } );
});

I subscribe with

Meteor.subscribe('tests', 7)

So in minimongo, i have now one document:

{
   _id: "xEXmYQABSbi79rLWS",
   ownerId: "rZd7ERscaQEF9rLeF",
   title: "Test",
   count: 10
},

Via the application and a method, I update the document as below:

tests.updateAsync({ _id: "ack5L5ivM5ACBeNpK" }, { $set: { count: 12 } });

I was expected to see an added message (as it is now a new document inside the publication) with all field.

and

I see a changed message with part of the document (the updated field). So, Minimongo is fulfilled with a partial information.

I hope it is clearer.

[jamauro]

Thanks. Subscription state is managed on the client so you won't see a added for this scenario because the server doesn't know what the client has by design.

I'm not entirely sure how a user could update a document by _id that they can't see in the UI but maybe I'm missing something.

When not using an _id selector, then it seems likely that it'll be a multi: true or upsert: true in which case the whole document(s) will be sent to the client. If they aren't found, they'll be added. But at the moment, I think they won't be tagged with the active .once subscriptionId which could be problematic. Not sure, I'd have to spend more time with it which I don't have at the moment. Maybe I can look more closely at this scenario down the line.

[harry-73]

Thanks for your answer.

I'm not entirely sure how a user could update a document by _id that they can't see in the UI but maybe I'm missing something.

It was to simplify but the _id can be provided via another document from another collection.

When not using an _id selector, then it seems likely that it'll be a multi: true or upsert: true in which case the whole document(s) will be sent to the client. If they aren't found, they'll be added. But at the moment, I think they won't be tagged with the active .once subscriptionId which could be problematic. Not sure, I'd have to spend more time with it which I don't have at the moment. Maybe I can look more closely at this scenario down the line.

👍