Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ignore channel etc. configuration on client and when no init #357

Open
edemaine opened this issue Sep 12, 2020 · 0 comments
Open

Ignore channel etc. configuration on client and when no init #357

edemaine opened this issue Sep 12, 2020 · 0 comments

Comments

@edemaine
Copy link

edemaine commented Sep 12, 2020

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:

unless Meteor.isServer and Mongo.Collection.prototype.configureRedisOplog

  Originals =
    insert: Mongo.Collection.prototype.insert
    update: Mongo.Collection.prototype.update
    remove: Mongo.Collection.prototype.remove
    find: Mongo.Collection.prototype.find

  reconfig = (config) ->
    config unless config?.channel?
  Mongo.Collection.prototype.insert = (data, config) ->
    Originals.insert.call @, data, reconfig config
  Mongo.Collection.prototype.update = (selector, modifier, config) ->
    Originals.update.call @, selector, modifier, reconfig config
  Mongo.Collection.prototype.remove = (selector, config) ->
    Originals.remove.call @, selector, reconfig config
  Mongo.Collection.prototype.find = (selector = {}, config) ->
    Originals.find.call @, selector, reconfig config

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant