This is the comment thread for the Migrating to Meteor 1.4 article in the Meteor Guide.
The comment thread for each article appears at the very bottom of the page. Use this thread to post:
Or anything else related to this topic that people could find useful!
I wasn’t sure where to post this, hope here is appropriate. Being that mongo is upgraded to v3.2, I’m assuming joins are possible, and therefore the need of using denormalizers as currently suggested is no longer required?
Or does it still hold true that:
MongoDB is a database where denormalizing is encouraged, and thus optimized for this practice.
Thanks in advance!
Although you can definitely use aggregations with Meteor and take advantage of the joining features, Meteor’s basic Mongo support via livequery doesn’t support aggregations, so denormalizing still tends to make sense.
I just ran “C:\utd\160723Socially>meteor update” and got the output below.
Should I run the update for all the packages as listed below?
160723Socially: updated to Meteor 1.4.
Your top-level dependencies are at their latest compatible versions.
Newer versions of the following indirect dependencies are available:
meteor update.What do you have now in .meteor/packages?
The migration guide doesn’t make it very clear how to update your local dev database if you don’t want to just meteor reset it. What’s the best way to do it?
Also, Compose.io doesn’t support WiredTiger as far as I know. Could running WiredTiger locally but on in production be a problem?
As you would migrate any database, connecting to localhost:3001/meteor, while meteor is running. I’ll try to make this clearer.
I’m not sure there are any differences in behaviour, but I guess there could be. In general, I’d probably worry more about making sure my staging environment mirrored production as closely as possible and testing properly there. There are enough differences between development and production that small differences in db behavior tend to not show through.
I get the part about connecting to localhost:3001/meteor, but what do you do next?
mongodump -h localhost -port 3001 -db meteor
… doesn’t seem to work with 1.4 apps (it does work with 1.3.5.1 apps). So as long as you mongodump before updating, I guess there’s still a way to migrate the db.
I do know that doing this still works with 1.4:
mongorestore -h localhost -port 3001 -db meteor
Is the reason that mongodump doesn’t work with 1.4 something to do with using the 3.2 version of Mongo?
It works for me with a vanilla 1.4 app – perhaps it doesn’t work with a 1.4 app that is using an old db?
EDIT:
Worked for an updated app too. I’m not sure what you are seeing @babrahams
I just took an existing Meteor 1.3.5.1 project, dumped the database, did a meteor update followed by a meteor reset. Successfully restarted the app, did mongorestore -h localhost -port 3001 -db meteor and saw the restored data. Everything fine so far and working as expected.
Then I tried (for interest sake – in case on some other app I wanted to update now and switch to Wired Tiger by means of a quick and easy meteor reset later) to mongodump -h localhost -port 3001 -db meteor, which didn’t dump the database. It created a folder called dump, with a nested folder called meteor, but there were no contents to the meteor folder. The mongo version is 3.2.6, node 4.4.7, Meteor 1.4, OSX 10.11.5.
Ah, yeah I see the same behavior when dumping from a 3.2 DB.
But the issue is that we were using an old version of mongodump (I’m pretty sure you were too because you wrote -port rather than --port and that worked with mongodump version 2.6 but not version 3.2 for me).
When I use a 3.2 version of mongodump, all is good.
Haha… you’re absolutely right @tmeasday. Thanks for picking up on that!
With mongo 3.2 installed (instead of 2.6!), the command to dump the local database is:
mongodump --host localhost --port 3001 --db meteor
And dump this can be restored with:
mongorestore --host localhost --port 3001 --db meteor
not a fan of pre-releasing breaking changes through 1.3.5.x rather than 1.x that would comply with versioning convention. Spend a week pondering as to why my mongo stopped working.
I belief that since your recommend to first upgrade to 1.3.5.1 before to 1.4 to make sure that everything is in order as both versions share same code it is then not backwards compatible breaking the convention where the at least the last numbers of version are just patches. Otherwise I just downgraded and still have issues with mongo.
Also, Compose.io doesn’t support WiredTiger as far as I know. Could running WiredTiger locally but on in production be a problem?
Compose offers 4g wired tiger w/3 nodes for $133 a month. Deployments -> Create Deployment -> MongoDB (not classic) -> Check the box.
My understanding is mmap and WiredTiger are API compatible. Here’s a MongoDB blog post for more info.
Everything in order apart from the breaking changes? For instance Mongo + Node were not updated in 1.3.5.1
Generally speaking, “downgrading” isn’t really supported. Why not just revert to an older version of your code?
Current Meteor version: 1.3.4.1
“meteor update --release 1.3.5.1” and “meteor update” both result in the same error trace below. Not sure what to do about it…
=> Errors while initializing project:
While loading package fourseven:scss@3.4.3:
error: Command failed:
module.js:340
throw err;
^
Error: Cannot find module '…/'
at Function.Module._resolveFilename (module.js:338:15)
at Function.Module._load (module.js:280:25)
at Module.require (module.js:364:17)
at require (module.js:380:17)
at Object.
(/home/mad/.meteor/packages/fourseven_scss/.3.4.3.9ec67g++os.linux.x86_64+web.browser+web.cordova/plugin.compileScssBatch.os.linux.x86_64/npm/node_modules/meteor/compileScssBatch/node_modules/.temp-1i4zv75/node_modules/node-sass/node_modules/cross-spawn/node_modules/spawn-sync/node_modules/try-thread-sleep/node_modules/thread-sleep/node_modules/.bin/node-pre-gyp:15:20)
at Module._compile (module.js:456:26)
at Object.Module._extensions…js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Function.Module.runMain (module.js:497:10)
npm ERR! Linux 3.19.0-65-generic
npm ERR! argv “node”
"/home/mad/.meteor/packages/meteor-tool/.1.3.5_1.1xxjkfx++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/bin/npm"
“rebuild” “–no-bin-links” "–update-binary"
npm ERR! node v0.10.46
npm ERR! npm v3.10.5
npm ERR! code ELIFECYCLE
npm ERR! thread-sleep@1.0.4 install: node-pre-gyp install --fallback-to-build
npm ERR! Exit status 8
npm ERR!
npm ERR! Failed at the thread-sleep@1.0.4 install script ‘node-pre-gyp install --fallback-to-build’.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the thread-sleep package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! node-pre-gyp install --fallback-to-build
npm ERR! You can get information on how to open an issue for this project with:
npm ERR! npm bugs thread-sleep
npm ERR! Or if that isn’t available, you can get their info via:
npm ERR! npm owner ls thread-sleep
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!
/home/mad/.meteor/packages/fourseven_scss/.3.4.3.9ec67g++os.linux.x86_64+web.browser+web.cordova/plugin.compileScssBatch.os.linux.x86_64/npm/node_modules/meteor/compileScssBatch/node_modules/.temp-1i4zv75/npm-debug.log
module.js:340
throw err;
^
Error: Cannot find module '…/'
at Function.Module._resolveFilename (module.js:338:15)
at Function.Module._load (module.js:280:25)
at Module.require (module.js:364:17)
at require (module.js:380:17)
at Object.
(/home/mad/.meteor/packages/fourseven_scss/.3.4.3.9ec67g++os.linux.x86_64+web.browser+web.cordova/plugin.compileScssBatch.os.linux.x86_64/npm/node_modules/meteor/compileScssBatch/node_modules/.temp-1i4zv75/node_modules/node-sass/node_modules/cross-spawn/node_modules/spawn-sync/node_modules/try-thread-sleep/node_modules/thread-sleep/node_modules/.bin/node-pre-gyp:15:20)
at Module._compile (module.js:456:26)
at Object.Module._extensions…js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Function.Module.runMain (module.js:497:10)
npm ERR! Linux 3.19.0-65-generic
npm ERR! argv “node”
"/home/mad/.meteor/packages/meteor-tool/.1.3.5_1.1xxjkfx++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/bin/npm"
“rebuild” “–no-bin-links” "–update-binary"
npm ERR! node v0.10.46
npm ERR! npm v3.10.5
npm ERR! code ELIFECYCLE
npm ERR! thread-sleep@1.0.4 install: node-pre-gyp install --fallback-to-build
npm ERR! Exit status 8
npm ERR!
npm ERR! Failed at the thread-sleep@1.0.4 install script ‘node-pre-gyp install --fallback-to-build’.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the thread-sleep package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! node-pre-gyp install --fallback-to-build
npm ERR! You can get information on how to open an issue for this project with:
npm ERR! npm bugs thread-sleep
npm ERR! Or if that isn’t available, you can get their info via:
npm ERR! npm owner ls thread-sleep
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!
/home/mad/.meteor/packages/fourseven_scss/.3.4.3.9ec67g++os.linux.x86_64+web.browser+web.cordova/plugin.compileScssBatch.os.linux.x86_64/npm/node_modules/meteor/compileScssBatch/node_modules/.temp-1i4zv75/npm-debug.log
Anecdotal evidence suggests you try
meteor remove fourseven:scss
meteor update
meteor add fourseven:scss