Mongo Cursor compatibilty

[arunoda]

I just peeked into the code and hope this is what returned from the publication. See: https://goo.gl/nj7LUe and https://goo.gl/VtquMH

If so, is there is possibility to have Mongo cursor compatible methods like .fetch(). That'll help things like FastRender to work properly (without patching it).

[stubailo]

@arunoda do you think we need to reproduce the entire Mongo cursor API? That means:

1. fetch()
2. _publishCursor(subscription)
3. forEach(func)
4. map(func)
5. count()
6. observe(callbackObj)
7. observeChanges(callbackObj)

Are some of these unnecessary/can be implemented in terms of others?

count is mongo specific, I think, because count would be part of the SQL query itself. I think map can be implemented in terms of forEach. I'm not 100% sure why we have observe and observeChanges as separate things - is there some history here @Slava? Do they do significantly different things under the hood?

Seems like most of these won't be a problem to implement, I'll add it to the tasks so maybe we will get to it (we have a limited amount of time for the experiment)

[arunoda]

I don't think we need to implement all. May be a set of the methods. So, then all the drivers could implement that cursor. Right now, I hope only mandatory method is _publishCursor. But having .fetch .map seems like a good idea. And implementing observe and observeChanges also a good thing. So, we can use it with other tools which accepts a mongo cursor.

So, basically we need to define an interface for DDP cursors. So, all the drivers can implement it. And other addons like fast-render and may be SSR and use them.

[stubailo]

@arunoda we now have 100% cursor compatibility on the client, going to take a look at the server part now.

[arunoda]

That's super awesome :) I will give it a spin for SSR and fast render stuff. . On 2015 අගෝ 22, සෙන at පෙ.ව. 2.53 Sashko Stubailo notifications@github.com wrote:

@arunoda https://github.com/arunoda we now have 100% cursor compatibility on the client, going to take a look at the server part now.

— Reply to this email directly or view it on GitHub https://github.com/meteor/postgres-packages/issues/3#issuecomment-133566578 .

[stubailo]

Yeah, let me know if you run into anything!

[arunoda]

Of course sure.

On Sat, Aug 22, 2015 at 4:41 AM Sashko Stubailo notifications@github.com wrote:

Yeah, let me know if you run into anything!

— Reply to this email directly or view it on GitHub https://github.com/meteor/postgres-packages/issues/3#issuecomment-133585920 .

[jchristman]

I think server-side implementation of the .observe method on knex query builder would be extremely useful. In code, it would be nice to be able to do:

exampleTable1
        .count('*')
        .innerJoin(exampleTable2,
                "exampleTable1.col1",
                "exampleTable2.col1")
        .where({
            "exampleTable2.col2": 1
        })
        .observe({
            added: function (sEvent) {
                // Do something when something is added
            },
            changed: function (newSEvent, oldSEvent) {
                // Do something when something changed
            },
            removed: function (oldSEvent) {
                // Do something when something was removed
            }
        });

My particular use case is this: I was trying to use this to aggregate data reactively server side into a Mongo collection to push to the clients. I know that the example does do a count and inserts it into an extra column client-side, but that does not work well for this use case. In this case, I want to be able to have a reactive count of the number of things in the database without actually publishing any of the things to the clients. To accomplish this, I was trying to run a PG query and upsert the result in a Mongo Collection that I could publish.

Perhaps there is a better way of doing what I am trying to do, but the .observe method on a knex query would accomplish this splendidly.

[stubailo]

Yeah I think that's just a missing method. I think all of the functionality is implemented already, we just need to add the endpoint.

[stubailo]

Try now after this commit: a7f3b743a6dff0c95d4c4eef5aa1c359dc8f55a0