Users and data lost after restarting meatier

Question

Users and data lost after restarting meatier

metstrike opened this issue 9 years ago · comments

Is this the expected behavior? When I stop meteor with Ctrl+C and then restart it, the created user and data is saved in Mongo. When I do the same with meatier, I can't login anymore and I have to sign-up the same username again. Also, all the lanes/notes data disappeared.

Bartek Kus · Answer 1 · Wed Feb 17 2016 08:32:23 GMT+0800 (China Standard Time)

At the moment, yes, it is the expected behavior.

metstrike.com · Answer 2 · Wed Feb 17 2016 08:45:03 GMT+0800 (China Standard Time)

Thanks for clarifying!

Patrick Lee Scott · Answer 3 · Wed Feb 17 2016 08:57:10 GMT+0800 (China Standard Time)

@metstrike This happens when running npm run build:db - pretty sure if you avoid that command it won't happen. npm run build:db is also called from npm run quickstart

"build:db": "node ./src/server/database/setupDB.babel.js"

./src/server/database/setupDB.babel.js imports ./src/server/database/setupDB.js which is where the database is configured/cleared:

import r from './rethinkdriver';

// ava is the test database
const databases = ['meatier', 'ava'];

const database = [
  {name: 'users', indices: ['email']},
  {name: 'lanes', indices: ['userId']},
  {name: 'notes', indices: ['laneId']},
];

export default async function setupDB() {
  for (let db of databases) {
    try {
      await r.dbCreate(db);
    } catch (e) {
    }
    let indices = [];
    const tables = await r.db(db).tableList().run();
    await Promise.all(tables.map(table => r.db(db).tableDrop(table)));
    await Promise.all(database.map(table => r.db(db).tableCreate(table.name)));
    database.forEach(table => table.indices.forEach(index => indices.push(r.db(db).table(table.name).indexCreate(index))));
    await Promise.all(indices);
  }
  await r.getPool().drain();
}

metstrike.com · Answer 4 · Wed Feb 17 2016 15:46:20 GMT+0800 (China Standard Time)

It feels like normal npm run quickstart should not clear up the database but rather some other command, for example npm run reset.

Matt Krick · Answer 5 · Thu Feb 18 2016 00:15:27 GMT+0800 (China Standard Time)

Ah gotcha, yeah quickstart is a run once type of thing. After that I run bs or prod or something that doesn't nuke the db.

Jeffrey Wescott · Answer 6 · Thu Feb 18 2016 03:02:49 GMT+0800 (China Standard Time)

Worth looking at? https://www.npmjs.com/package/rethink-migrate

Matt Krick · Answer 7 · Thu Feb 18 2016 05:06:35 GMT+0800 (China Standard Time)

a migrate won't work on the initial run since nothing's there.

So postinstall we have to do a few things:

init the DBs (create DBs, tables, and indexes)
Clear the DBs (in case a DB or table already exists)
Build the bundles (client, server)

After that, adding new tables requires step 1, but not step 2. I should probably add a new task like updateDBs that updates them without clearing them. Thoughts?

Bartek Kus · Answer 8 · Thu Feb 18 2016 05:28:07 GMT+0800 (China Standard Time)

I started to look into node-config it might be our best bet.
However a simple postinstall script can be use to achieve the same initial build, I can submit a PR with the proposed solution.

Bartek Kus · Answer 9 · Thu Feb 18 2016 05:30:03 GMT+0800 (China Standard Time)

we could move the create:db && build:client && build:server to postinstall script, then have start simply start the server in production.

We can make additional scripts such as reboot & restart, depending on what's needed, reboot could purge db, while restart just rebuild client & server.

Bartek Kus · Answer 10 · Thu Feb 18 2016 06:26:58 GMT+0800 (China Standard Time)

Here is what I'm proposing, what do you think @mattkrick ?

"scripts": {
    "postinstall":  "rimraf build && concurrent \"npm run build:db\" \"npm run build:client\" \"npm run build:server\"",
    "dev":          "NODE_ENV=development node ./src/server/server.babel.js",
    "prod":         "NODE_ENV=production node ./src/server/server.babel.js",
    "rebuild":      "rimraf build && concurrent \"npm run build:client\" \"npm run build:server\"",
    "restart":      "npm run rebuild && npm run prod",
    "restart:dev":  "npm run rebuild && npm run dev",
    "start":        "npm run prod",
    "start:dev":    "npm run dev",
    "build:client": "NODE_ENV=production webpack --colors --config ./webpack/prod.babel.js",
    "build:server": "NODE_ENV=production webpack --colors --config ./webpack/server.babel.js",
    "build:db":     "node ./src/server/database/setupDB.babel.js",
    "test":         "NODE_ENV=testing ava ./src/**/__tests___/**/*.js --verbose",
    "lint":         "xo src/**/*.js --plugin=react --env node --env browser --esnext --space --fix",
    "profile":      "NODE_ENV=production webpack --config ./webpack/prod.babel.js --profile --json > stats.json"
  },

metstrike.com · Answer 11 · Thu Feb 18 2016 06:51:14 GMT+0800 (China Standard Time)

It makes sense, I would suggest to simplify even more:

"setup" - instead of "postinstall"
"reset" - same as setup?
"start" - what is the downside if it includes rebuild, then we could
eliminate restart
"start:dev"
"build" - instead of "rebuild"
"help" - prints all these commands
"list" - lists all the packages
"logs"
"lint"
"profile"

The rest should probably be undocumented.

Here is the list of meteor commands, it would be nice to keep as much
similar as possible.

On Wed, Feb 17, 2016 at 2:27 PM, Bartek Kus notifications@github.com
wrote:

Here is what I'm proposing, what do you think @mattkrick
https://github.com/mattkrick ?

"scripts": {
"postinstall": "rimraf build && concurrent "npm run build:db" "npm run build:client" "npm run build:server"",
"dev": "NODE_ENV=development node ./src/server/server.babel.js",
"prod": "NODE_ENV=production node ./src/server/server.babel.js",
"rebuild": "rimraf build && concurrent "npm run build:client" "npm run build:server"",
"restart": "npm run rebuild && npm run prod",
"restart:dev": "npm run rebuild && npm run dev",
"start": "npm run prod",
"start:dev": "npm run dev",
"build:client": "NODE_ENV=production webpack --colors --config ./webpack/prod.babel.js",
"build:server": "NODE_ENV=production webpack --colors --config ./webpack/server.babel.js",
"build:db": "node ./src/server/database/setupDB.babel.js",
"test": "NODE_ENV=testing ava ./src//tests_//.js --verbose",
"lint": "xo src/__/.js --plugin=react --env node --env browser --esnext --space --fix",
"profile": "NODE_ENV=production webpack --config ./webpack/prod.babel.js --profile --json > stats.json"
},

—
Reply to this email directly or view it on GitHub
#79 (comment).

Bartek Kus · Answer 12 · Thu Feb 18 2016 07:19:44 GMT+0800 (China Standard Time)

postinstall

is part of the npm lifecycle, which means it will be naturally triggered once npm install is done executing. If we change it to setup then the user would have to trigger it by doing:

npm run setup

So as you can see there are already certain things that we can take advantage of in the npm lifecycle but imitating all meteor commands might be counter productive since meteor had to employ their own package manager and thus required certain commands to exist.

For example
http://docs.meteor.com/#/full/meteorshowmeteor publish
might be redundant seeing how npm publish already does this natively
Meatier uses npm vs reinventing the wheel like Meteor did, hence we want to stay as closely to npm standard as possible. This is also the philosophy of Webpack, to extend the existing npm environment, not to redesign it in our own way.

Patrick Lee Scott · Answer 13 · Thu Feb 18 2016 07:25:29 GMT+0800 (China Standard Time)

I agree @bartekus, postinstall makes sense. I do like having a "reset" for resetting the project.

metstrike.com · Answer 14 · Thu Feb 18 2016 08:35:07 GMT+0800 (China Standard Time)

I agree, let's not change whatever goes with npm naturally. If
postinstall is executed by npm automatically, then user should be
able to do all they need with the following minimum set of commands:

"reset" - "nukes" the DB
"start" - includes "rebuild", so we don't need restart
"start:dev"
"build" - instead of "rebuild"
"help" - prints all these commands
"lint"
"profile"

On Wed, Feb 17, 2016 at 3:25 PM, Patrick Scott notifications@github.com
wrote:

I agree @bartekus https://github.com/Bartekus, postinstall makes sense.
I do like having a "reset" for resetting the project.

—
Reply to this email directly or view it on GitHub
#79 (comment).

Bartek Kus · Answer 15 · Thu Feb 18 2016 11:37:27 GMT+0800 (China Standard Time)

Ok, here us the modified script list:

 "scripts": {
    "postinstall":  "rimraf build && concurrent \"npm run build:db\" \"npm run build:client\" \"npm run build:server\"",
    "reset":        "npm run postinstall",
    "dev":          "NODE_ENV=development node ./src/server/server.babel.js",
    "prod":         "NODE_ENV=production node ./src/server/server.babel.js",
    "build":        "rimraf build && concurrent \"npm run build:client\" \"npm run build:server\"",
    "restart":      "npm run build && npm run prod",
    "restart:dev":  "npm run build && npm run dev",
    "start":        "npm run prod",
    "start:dev":    "npm run dev",
    "build:client": "NODE_ENV=production webpack --colors --config ./webpack/prod.babel.js",
    "build:server": "NODE_ENV=production webpack --colors --config ./webpack/server.babel.js",
    "build:db":     "node ./src/server/database/setupDB.babel.js",
    "test":         "NODE_ENV=testing ava ./src/**/__tests___/**/*.js --verbose",
    "lint":         "xo src/**/*.js --plugin=react --env node --env browser --esnext --space --fix",
    "profile":      "NODE_ENV=production webpack --config ./webpack/prod.babel.js --profile --json > stats.json",
    "help":         "npm run"
  },

I would propose keeping restart and start as separate since otherwise each deployment would result in wasted operations, being that after postinstall is completed, 2/3 of the process would be repeated with issuing of the start command.