How are we handling DB migration?

[Zren]

@sizzlemctwizzle & whoever else has access to the production db.

This came up in #335. How do you want me to handle migration?

Personally, I'd prefer having a ./models/migration/ folder, with scripts called 2014-08-28.js which would connect with mongoose normally, but run operations. They'd accept the CONNECT_URI env var. These would have to be run by someone with access to the db however.

Another option would be to version our schema, then run scripts automatically on server run. This'd be a pain to implement as we'd have to write an entire migration feature ourselves unless someone knows one.

Thirdly, we could lazily migrate (which is how you normally handle schemaless databases) in which each document will be updated as it's updated.

[Martii]

This is definitely a @sizzlemctwizzle thing. I don't have access to the DB and possibly won't. Migrations of the DB are handled currently by sizzle directly. It would be helpful to have something development side here on GH though. See related #233, #285 and probably some more with DB migrations/alterations needed. GM just finalized the metadata block syntax today with version 2.2. So we have a bit to catch up on although our parseMeta routine is "safe" from destruction albeit incorrect at the moment.

[sizzlemctwizzle]

I've mostly done lazy migration in the past. But when I got the namespace
slug out of installName I used a script. I prefer lazy migration and only
using a script when that isn't enough.
On Aug 28, 2014 3:38 PM, "Chris Holland" notifications@github.com wrote:

@sizzlemctwizzle https://github.com/sizzlemctwizzle & whoever else has
access to the production db.

This came up in #335
#335. How do you want
me to handle migration?

Personally, I'd prefer having a ./models/migration/ folder, with scripts
called 2014-08-28.js which would connect with mongoose normally, but run
operations. They'd accept the CONNECT_URI env var. These would have to be
run by someone with access to the db however.

Another option would be to version our schema, then run scripts
automatically on server run. This'd be a pain to implement as we'd have to
write an entire migration feature ourselves unless someone knows one.

Thirdly, we could lazily migrate (which is how you normally handle
schemaless databases) in which each document will be updated as it's
updated.

—
Reply to this email directly or view it on GitHub
#337.