-
-
Notifications
You must be signed in to change notification settings - Fork 8
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
Migration 3.0 #13
base: master
Are you sure you want to change the base?
Migration 3.0 #13
Conversation
Hello, does someone know when this can be merged? |
It is not yet usable due to problems with the new asynchronous package loading logic. I am waiting for information about this so I can update the package. |
I have this loaded locally and at least in initial tests its seems to work. I did this: https://guide.meteor.com/writing-atmosphere-packages.html#overriding-atmosphere-packages and then just had to mess around with the requirements. @plbkbx is there a particular bug you are seeing? I'm curious why my case seems to work and yours doesn't. I do do my RedisOplog.init inside of a Meteor.startup call which might help resolve the loading order issue you are talking about? I'm not entirely sure what about RedisOplog matters if stuff is loaded out of order. |
For an explanation of the issue I send you to https://forums.meteor.com/t/order-of-loading-packages/61112/9. The problem is insidious and could occur the particular cases. |
Right, I get that packages won't load in the right order, but looking at the code of this package I'm not entirely sure why that matters. Do you have an example repo showing redis-oplog not working correctly? It could be helpful if anyone makes an update to this package. |
This package does a Monky Patch of the Mongo.Collection constructor to register all the instances created (mongoCollectionNames.js). If another package is run first and creates a collection it is not recognized and generates an error. I don't have an example with redis-oplog but I generated a simple one to verify the problem. |
Ah ok, so not really a problem with this package at all, but more a Meteor issue. I don't think there is anyway for this package to resolve that problem, maybe it could give an option to convert and register the collection after the fact. For people, like me who don't need redis to be connected to any collections from other packages I think this will work just fine, so in theory this PR could go through. I don't have the expertise in it though to know all the possible use cases that would need to be checked. |
24e9543
to
a0ffa1e
Compare
Published cultofcoders:redis-oplog@3.0.0-rc.1 with the latest from this branch for user testing targeting 3.0-rc.4 for now. |
I don't have permissions to push to this branch, but I only adjusted package.js |
I got this error with 3.0-rc.1 under meteor 3.0.1
|
rc.2 is from another branch. If that one works, we will move to that branch. |
rc.2 has the same problem. I also tested it without wildhart:jobs. I get the same error with 'users' instead of 'jobs_dominator_3' then. |
Interesting. |
b1053e5
to
4668d1b
Compare
It seems like client-side updates to the |
@klablink can you grand me access to your fork so that I can push updates? Thanks! Also can we potentially merge this with this PR: cult-of-coders#405 |
Hi @StorytellerCZ , I have given you the rights to the project. |
Porting to Meteor version 3.0. The package is not backward compatible because it replaces kernel components that are now asynchronous. Tests can only be performed with packages compatible with version 3.0. All files are migrated to standard.js style.