minimongo does not support observeChanges unordered with limit #1643
Comments
This sounds serious but please provide a cloneable repo with both apps in it. For example, without knowing what packages are in your app (esp packages like insecure and autopublish) I can't know if I'm doing the same thing as you. I will reopen this bug if you post a complete replication with precise steps. |
Sure thing. I was going to just ran out of time that day
|
Here is a repo that will reproduce both issues: https://github.com/Tarangp/meteor-ddp-bugs
|
Bug 2 is "works as expected", I think. When you create a collection on the server with Perhaps it would be nice to have a flag to As far as Bug 1 goes: yes, I'm not sure why that limitation exists. Maybe the unordered code doesn't support skip/limit? It dates from @n1mmy 's first implementation of minimongo observeChanges with skip/limit. That usage does seem perfectly reasonable to me. It's possible that we can just remove the if (!options._allow_unordered && !ordered && (self.skip || self.limit))
throw new Error("must use ordered observe with skip or limit"); entirely? Renaming issue to match. |
Regarding the "acting as a client to some DDP server" mode on server: Does this create, or allow to create, a minimongo live? DB on the server B (similar to clients), to enable for resyncs after a period of disconnection between server A and B? The only ddp relay/proxy pointers I could find were open questions: |
Hm, server B is "acting as a client to a DDP server". If B would actually hold real mongodb collections that it could sync back to server A (instead of just a minimongo cache), this would even be better! -> persistent, indexed replica (relevant subset) closer to the client, disconected operation, two-way sync What is your assessment, is this the use-case here, or possible? |
I could think of these code paths making sense:
|
There is a comment in |
Note that #1866 had a reproduction. |
They used to run the query twice: once for the actual result and once to set up the observe. Now it shares the work between the observe and the actual query. This required me to inline the _depend helper, but I actually think this made what's going on more direct and clear. Drop the _allow_unordered hack. I'm not convinced that it was ever truly valid; the observe code really doesn't support unordered observes with skip and limit, and I could not remember what it was about count's use that made it hypothetically safe. Easier to just remove the hack (until we maybe eventually actually fix #1643) Stop using Deps.Dependency in an unidiomatic way; just use Deps.currentComputation directly.
whoops, the auto-closer was a little over-zealous here! |
As discussed in this thread, Minimongo doesn't currently support using |
I've found a couple of issues with server to server ddp. I'll make a sample project too that shows the issues but they're along the lines of this:
Server A
Server B
Server side js
Client side JS
The first error with publishing the collection with limit and sort gives back an error that there is no
sort
key provided.The second error with inserts is that the methods (/collections/insert) can't be found on server b.
The text was updated successfully, but these errors were encountered: