Problem with publish/subscribe in React

lagartoverde · September 4, 2021, 9:06am

Hello I have this problem and maybe you can help.
I have a collection who comes from a different database as the others, and I created the collection like

const db2 = new MongoInternals.RemoteCollectionDriver(...);
const JtiJobs = new Meteor.Collection('jobs',{ _driver: db2,  _suppressSameNameError: true } )

then I wrote my publication as

Meteor.publish("JtiJobs", function(args) {
  return JtiJobs.find(args);
});

Until this point everything works great, I can get all the data I want on the backend without any problems, but I wrote a component to show that data on the frontend and I used the withTracker HOC as I’m using react

export default withTracker({
  getMeteorData () {
    const handlerJob = Meteor.subscribe('JtiJobs', {_id: "QNdRnbR2YFkf62eq3"})
     
    const userId = Meteor.userId();
    
    return {
      currentUser: Meteor.user(),
      listLoading: !handlerJob.ready(),
      jobs: JtiJobs.find({}).fetch(),
    };
  },
  pure: true,
})(Charges);

When accessing the listLoading prop it works as expected it says true for a moment and then it loads and says false, but the data never loads in this.props.jobs.
Maybe I’m missing something but I followed every tutorial I could find and I don’t see where I’m wrong.
Thank you for the help

paulishca · September 4, 2021, 9:38am

Where is your Oplog for db2? I think that is necessary for reactivity.

github.com

meteor/docs/blob/version-NEXT/long-form/oplog-observe-driver.md

March 18, 2014

In Meteor 0.7, we reworked how Meteor gets real-time database updates from MongoDB.

The key method that Meteor adds to the MongoDB API which makes it into a real-time database API is [`cursor.observeChanges`](http://docs.meteor.com/#observe_changes). `observeChanges` run an arbitrary MongoDB query, returns its results via `added` callbacks, and then **continues to watch the query** and calls additional callbacks as its results change.

Most users don't use `observeChanges` directly, but whenever you return a cursor from a [publish function](http://docs.meteor.com/#meteor_publish), Meteor calls `observeChanges` on that cursor and provides it with callbacks which publish the query's changes to clients.

Previous versions of Meteor only had one strategy for implementing `observeChanges`: the "poll-and-diff" algorithm, implemented by the `PollingObserveDriver` class.  This approach re-runs the query frequently and calculates the difference between each set of results. This code is simple and has historically contained very few bugs. But the cost of the `PollingObserveDriver` is proportional to the poll frequency and to the size of each query result, and the time from database change to callback invocation depends on whether the write originated in the same Meteor server process (very fast) or in another process (up to 10 seconds).

Starting with Meteor 0.7.0, Meteor can use an additional strategy to implemnt `observeChanges`: **oplog tailing**, implemented by the `OplogObserveDriver` class.
Meteor now knows how to read the MongoDB "operations log" --- a special collection that records all the write operations as they are applied to your database. This means changes to the database can be instantly noticed and reflected in Meteor, whether they originated from Meteor or from an external database client. Oplog tailing has different performance characteristics than "poll-and-diff" which are superior in many cases.

`OplogObserveDriver` needs to understand the meaning of MongoDB [selectors](http://docs.meteor.com/#selectors), [field specifiers](http://docs.meteor.com/#fieldspecifiers), [modifiers](http://docs.meteor.com/#modifiers), and [sort specifiers](http://docs.meteor.com/#sortspecifiers) at a much deeper level than `PollingObserveDriver`. This is because it actually needs to understand how write operations that it sees in the oplog interact with queries, instead of just relying on the MongoDB server to repeatedly execute the query. To deal with these structures, `OplogObserveDriver` uses Meteor's implementation of the MongoDB query engine, [Minimongo](https://github.com/meteor/meteor/tree/master/packages/minimongo), which Meteor also uses as its client-side local database cache.

As of Meteor 0.7.2, we use `OplogObserveDriver` for most queries. There are a few types of queries that still use `PollingObserveDriver`:
 * [Selectors](http://docs.meteor.com/#selectors) containing geospatial operators, the `$where` operator, or any operator not supported by Minimongo (such as `$text`)
 * Queries specifying the `skip` option
 * Queries specifying the `limit` option without a `sort` specifier or with a sort based on `$natural` order
 * [Field specifiers](http://docs.meteor.com/#fieldspecifiers) and [sort specifiers](http://docs.meteor.com/#sortspecifiers) with `$` operators such as `$slice` or `$natural`

This file has been truncated. show original

lagartoverde · September 4, 2021, 11:08am

@paulishca thanks for your answer, the second database is also used on a different meteor app and has set up a Redis replica for Oplog, but indeed I didn’t configure anything on this application for the Oplog of that second database.
How should I do it?
I know how to configure the Oplog at the application level but never configured it for a individual database

paulishca · September 4, 2021, 11:38am

I will have to leave this to someone who’s done this before. I personally don’t think you can be reactive with two different DBs based on Oplogs.
I hope not to mislead here… You could look into observers which is basically the link I shared with you earlier or here: ([Solved] Meteor observe not working properly in 1.6) or since you use the Mongo Driver, perhaps directly Mongo tech like https://docs.mongodb.com/manual/reference/method/db.collection.watch/. If not too critical I’d go with polling. Another way is to keep a “trigger” on your main DB if you need to update based on Inserts. Example:

I save all teams and team members in a “secondary” DB.
In my main DB I keep a collection of the number of team members in a team. (When I write a team member to a team in DB2 I also increment the counter in DB1.) I subscribe to DB1 (for which I use the Oplog). In React, with a useEffect() dependent on the counter, I pull data if the counter changes. I never observe/subscribe data sets. In most cases for Insert/Remove records it is so much cheaper to observe counters in counters collections. In case of Updates of documents it is a different story :).