It seems like the server can’t find any documents in the collection I made, even though there are many documents in it… and I don’t know why it’s behaving like this.
So I figured it might be because the server isn’t subscribed (although the client is), but I can’t access Meteor.subscribe() server-side, it says it’s undefined. I have also double-checked all values such as notificationId and userId, they’re correct.
It can run Notifications.update() and change the values successfully (if I comment out the if statement) but otherwise it’s always throwing an exception saying it can’t find anything.
I have also tried running Notifications.find({}).fetch() and it doesn’t return anything of relevance, and Notifications.find({}).fetch()[0].userId (and all other fields) returns undefined.
However, you should note that normally, your index.js would contain just a bunch of import statements, one of which would be the method, above, in its own file. See the Meteor Guide here.
Sprinkle some console.log statements in to help you isolate other issues (invalid _ids, etc.). If you use vscode, you can debug client and server code from your desktop.
1, Show us how you’re using the Meteor.call to your method - are you waiting for the response?
Thanks for your helpful tips, I’ve now implemented your recommendations, as well as from the guide.
I’m already logging the variables etc and they’re correct, but it’s still not finding the documents.
As for the meteor call, this is my code (in body.js)
You should not include userId in publication and method as param. You can have that value in the method by calling Meteor.userId() and this.userId in publication.
Just to add to this, I wasn’t aware that it was possible to have a collection without an _id field. However, it turns out that it can be done, but there are some consequences:
You can’t do this if you have replica sets. For Meteor, that means no oplog-based reactivity.
Meteor’s minimongo uses the _id field throughout - including for pub/sub.
This ability has been deprecated since MongoDB 3.2.
It seems so unlikely that there isn’t an _id field, that I need to double-check:
@pawpey: is that document example actually from querying the database?
Your _id field is a Mongo ObjectID, so any operations you need to perform on it (like if(Notifications.find({ _id: notificationId, ... will require you use an ObjectID to search with.
Yes it is an ObjectID, so I really don’t know why it refuse to work. As a side note, it doesn’t matter what key I search for, I can remove the notificationId and only go for userId (or none at all) and it still doesn’t work.