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

Packages should be able to seed the database when bootstrapped #118

Open
timelf123 opened this issue Sep 19, 2016 · 5 comments
Open

Packages should be able to seed the database when bootstrapped #118

timelf123 opened this issue Sep 19, 2016 · 5 comments
Assignees

Comments

@timelf123
Copy link
Contributor

timelf123 commented Sep 19, 2016

Either with an env variable and JSON seed file (more flexible, can touch multiple collections), or a more simple one collection check. Example for a package called packageName, this code will run a seed function only if the collection does not exist

 // Seed the database...
 mongoose.connection.db.listCollections({
         name: 'packageName'
     })
     .next(function(err, collinfo) {
         if (!collinfo) {
             console.log('packageName collection does not exist, seeding!');
             var defaultData = require('./server/models/packageName.seed');
             var Model = mongoose.model('packageName');
             Model.insertMany(defaultData, function(err, r) {
                 if (err) {
                     console.log(err);
                 }
                 if (r) {
                     console.log(r);
                 }
             });
         }
     });
packageName.seed

module.exports = [{
  foo: bar,
  baz: fuzz
}];
@ADSKLowenthal
Copy link
Contributor

@timelf123 We actually manage this as a separate package that allows us to run migration scripts at server launch.

Part of the problem I see here is that the seed data need to be idempotent or you'd just add data every time the server restarted. Our migrations are coded to check if they've already performed their work and just return if they have.

In fact, in production this would run code for each worker, we had to use an npm package mongoose-mutex to ensure that only one worker was running a migration at a time.

I agree that general data migration functionality would be helpful. Though I believe it may be best to start as a module.

@ghost
Copy link

ghost commented Nov 16, 2016

Also this should record what was run, and when, and the result, very similar to larvel's migrations:
https://laravel.com/docs/5.3/migrations

This includes its own collection migrations that stores the results, so a migration is checked against it's run history, and the migration "type" of:

  • Run Once
  • Run on a Cron schedule
  • Run on demand (user clicks a button)

@timelf123
Copy link
Contributor Author

I'm all in on the module idea. @ADSKLowenthal when you have some time would you mind spearheading the initial repo creation and getting something going?

@clowenhg
Copy link
Contributor

clowenhg commented Nov 16, 2016

@timelf123 Sure, might not be till the weekend. We do have a migrations module we use. It's not nearly as robust, but could be a good starting point.
@vtdave @rjVapes Do we think this is something from scratch, or should we consider putting our migrations module through OSSA?

@clowenhg clowenhg self-assigned this Nov 16, 2016
@timelf123
Copy link
Contributor Author

@clowenhg no rush, and if it works that's even more than I was hoping for. Just looking for a place to start hacking ;)

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

No branches or pull requests

4 participants