You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Request 1: When redis-oplog doesn't init on the server (when redisOplog isn't in settings.json and no REDIS_OPLOG_SETTINGS environment variable is set), I propose that redis-oplog still modify Collection.{insert,update,remove,find} to ignore any redis-oplog-specific configuration arguments like channel: "...".
Motivation: I'd like to deploy with redis but test locally using standard Meteor (so I don't need to run a redis server locally). I'm adding fine-tuning configurations like channels for the deployed version to be fast, but then I can't run without redis.
Request 2: On the client, where channels don't make sense, I propose that redis-oplog still modify Collection.{insert,update,remove,find} to ignore any redis-oplog-specific configuration arguments like channel: "...".
Motivation: I (and presumably many others?) use Optimistic UI Meteor methods, where both server and client (in simulation) use the same line of code (e.g. Messages.insert(..., {channel: "..."}) to modify the same collection. But currently the client crashes because Meteor/Mongo assumes the second argument is a callback. (Unless you write two versions of every operation in every method, as hinted at in the optimistic UI document.)
Currently I have the following workaround to both requests:
But it would be better to do it properly, in particular using redis-oplog's checking of config objects to decide whether the last argument is a callback or needs some redis-oplog-specific keys removed.
Request 1: When redis-oplog doesn't init on the server (when
redisOplog
isn't insettings.json
and noREDIS_OPLOG_SETTINGS
environment variable is set), I propose that redis-oplog still modifyCollection.{insert,update,remove,find}
to ignore any redis-oplog-specific configuration arguments likechannel: "..."
.Motivation: I'd like to deploy with redis but test locally using standard Meteor (so I don't need to run a redis server locally). I'm adding fine-tuning configurations like channels for the deployed version to be fast, but then I can't run without redis.
Request 2: On the client, where channels don't make sense, I propose that redis-oplog still modify
Collection.{insert,update,remove,find}
to ignore any redis-oplog-specific configuration arguments likechannel: "..."
.Motivation: I (and presumably many others?) use Optimistic UI Meteor methods, where both server and client (in simulation) use the same line of code (e.g.
Messages.insert(..., {channel: "..."})
to modify the same collection. But currently the client crashes because Meteor/Mongo assumes the second argument is a callback. (Unless you write two versions of every operation in every method, as hinted at in the optimistic UI document.)Currently I have the following workaround to both requests:
But it would be better to do it properly, in particular using redis-oplog's checking of config objects to decide whether the last argument is a callback or needs some redis-oplog-specific keys removed.
Related to #348.
Perhaps this is what
overridePublishFunction
was? (#323)The text was updated successfully, but these errors were encountered: