We have tried with {reactive:false}, but we still see polling queries every 10 secs on MongoDB.
Hmm, you may want to look into ways of accessing mongodb directly rather than a meteor collection.
There should be some packages on atmosphere that let you bypass meteor and access the native mongo driver for your own static queries.
Also, I think meteor also exposes that with an api named something like mongoInternals that Iām not experienced with but worth looking into.
I use both the official MongoDB driver and Mongoose for some of my other projects. I recommend either one.
Well how about that ā¦
A version of https://atmospherejs.com/richsilv/dumb-collections just got released.
Might be relevant to this conversation.
@Sparser - Can you please give some pointers how to fetch result sets manually to client and prevent reactivity ?
If you really want to continue to use collections you could use a server method to get the data out of the DB, then insert the results into a client only collection (initialized with null instead of the name of the collection).
var MyCollection = new Meteor.Collection(null);
Meteor.call('getData', function (docs) {
_.each(docs, function (x) {
MyCollection.insert(x);
});
});
The point of reactive:false is to stop the any template or autorun that uses that cursor from re-running when the cursor changes, on the client. This wonāt stop Meteor from polling the database for changes. If you call a subscription your database will be polled(or the oplog observed).
1 Like
You have two alternatives there:
a) Donāt use the built in accounts system
b) Fork the accounts packages, change their queries and publications so that they are not reactive
But (b) will require you to change a lot of things since the whole accounts system is built around the idea of reactivity.
Therefore, I think youāll be better of doing (a) and writing your own non-reactive accounts system.
Iāve reached this interesting conversation, and I want to ask for your opinion in a very similar situation as @sambapotla:
- I donāt need reactivity (at least right now, maybe in middle-term future for notifications, but letās assume I donāt need it at all). Actually, letās say I donāt want reactivity.
- Why using Meteor then? Because I have a veeery tight time constraint, Iāve been the last 2 years mainly a Frontend developer (though I have some Java backend knowledge from years ago), and Meteor seems to me a super fast way of building a website with my, letās say, limited knowledge.
- So for āavoidingā reactivity, I am basically doing Method calls, because as I understand it, methods are not reactive (am I right?).
This makes any sense?
Also @Sparser, you commented that making methods is a ton of work. If I didnāt care about reactivity, I would make use of publish and suscriptions, right? So I think: to do saves/updates checking authentication would be need to make Allow/Deny rulesā¦ (am I right?), meaning that the work will be more or less the same.
Sorry if I say too much wrong sentences, I am just trying to make 100% sense of Meteor in my head, but I think I am missing pieces in a bunch of places.
Cheers!!
Yes @eviljohn, I am same boat as you for all three points mentioned by you. My app doesnāt need reactivity other than a screen, and we have very few developers to build the app.
I am not sure of addiotional effort required for methods approach -
Server side, finding data from database - same effort, query in method vs publish block of code
Additional effort on client, method success call puting data into a ReactiveVAR or something to make it accessable for template helpers. Whereas, subscription puts data in minimango, and helpers would read from minimongo.