@marco, No, definitely not looking for it to be like Rails. But the concept of having a well-defined database schema versionizing structure and command to go up/down is very intelligent.
I like your approach of having three (as opposed to my two) different types of database initialization: a) cleanAndInit: runs automatically in test/dev mode, cleans out the database, restructures with props/schema, reseeds data. b) init: runs manually using something like jake, is idempotent, and guarantees the database structure is correct. c) validate: runs automatically with every app launch, validates the structure matches the database config file, but makes no changes, just exits with proper error message if it fails. If I can think of a sane way to extrapolate what I do into a useful open-source tool, I will. I always do. https://github.com/deitch :-) On May 29, 9:53 pm, Marco Rogers <[email protected]> wrote: > Node isn't like rails in that it tries to give you solutions for the whole > stack. So it sounds like you're not looking for node conventions but > framework conventions. Honestly there aren't many at the database level. > What I've seen is that people have been building up their own database > conventions based on their own experience and preferences. Frameworks like > geddy have true data models a la rails. But I haven't seen a good system > for managing data migrations. > > That said, I don't think you want to run your schema validations by default > every time the app starts. IMO, data migrations are part of deployment, not > runtime. You could check some schema version on startup and fail to start. > Then that would let you know that you neglected to run some migration > routines with this release. For running tasks, node has > jakehttps://github.com/mde/jake. So once you have your migration routines, > you can set them up to run as jake db:migrate and put it in your deploy > scripts. > > I'm not sure if this helps, but that's what I got. You should build a > migrations tool and open source it :) > > :Marco > > > > > > > > On Tuesday, May 29, 2012 10:40:04 AM UTC-7, deitch wrote: > > > When I launch my app in test or dev, it runs a database initializer, > > based on config file, that cleans out the db entirely, loads the > > properties, loads the seed data. Works fine. > > > Looking for a pattern for similar in production. > > > a) Is there anything like "rake db:migrate" from Rails for node? > > b) What patterns are people using? I am tempted to have the db > > initialize split into two functions: initialize(), which runs > > automatically in dev/test, which always cleans out and resets the db, > > and validate(), which runs automatically in beta/prod and ensures that > > the database properties are up to speed with the current version of > > the properties description file but does not clean it out. > > > e.g. new view "abc" wasn't in the last release, so I build it into my > > db properties/schema file. Now every test will create it for local > > test db. The moment I deploy (git using heroku, jitsu tools, manually, > > whatever), that view will *not* be in my managed database, and I am > > stuck. So validate() on launch ties properties to code version (good). > > But modifying database every time app starts seems risky. > > > Thoughts? -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
