8 comments

• Buthrakaur commented  ·  May 17, 2012 4:40 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  @jameymcelveen: we're using Migrator.NET (it's successor respectively: https://github.com/schambers/fluentmigrator ) in our application - just make sure you run your migrations on application start. No need for some special AppHarbor features IMO.

• antongogolev commented  ·  September 12, 2011 2:42 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  For the time being you can try http://code.google.com/p/octalforty-wizardby/ and integrate it into your build process.

• jameymcelveen commented  ·  September 10, 2011 9:54 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  Would love to have migrations run as part of deployment. Something like http://code.google.com/p/migratordotnet/

• erichexter commented  ·  August 31, 2011 6:30 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  AH has been such a great dev and deploy story for me. This is the one must have feature that is still needed.! Even if the first pass only supported upgrades, that would be huge.

• PawelPabich commented  ·  March 28, 2011 3:38 p.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  Until you guys come up with a comprehensive solution can you just simply call a well defined MsBuild target and let people deal with database upgrades?
  E.g. UpgradeDatabase and DowngradeDatabase. In most cases UpgradeDatabase will be enough. It's better to have something now then nothing for long time and force people to use hacks :). UpgradeDatabase should be called right before the app gets deployed to a web server. More details here:
  http://www.pabich.eu/blog/archive/2011/03/28/Automated-database-deployments-to-AppHarbor.aspx

  Any thoughts ?

  Pawel

• ferventcoder commented  ·  January 14, 2011 2:33 p.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  I don't want to limit people from using their framework of choice for migrations. Everyone has different opinions and that is fine, that's why there are so many options. :D

  If you decide to make it pluggable, just let me know how I can hook RH into it so it can be an option.

• ferventcoder commented  ·  January 14, 2011 2:22 p.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  Disclaimer: I am the maintainer of a migrations tool named RoundhousE.

  I use RoundhousE (RH) together with FNH/NH and SchemaExport (during initial development) / SchemaUpdate (once in production) to drive migration changes.

  RH uses plain old sql scripts to drive changes to databases. It doesn't yet support MySQL, but that doesn't mean it can't very quickly support it.

  http://projectroundhouse.org (the download comes with a sample for SQL to show how it works).

  I work on a set of tools known as the Chuck Norris Framework. We dub it as a developer productivity suite because it allows developers to get framework concerns out of the way. We are focused on removing pain, which seems very close to what AppHarbor also does. :D

• Admintt (Admin, AppHarbor) commented  ·  January 14, 2011 12:01 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  This is something we are thinking a lot about!

  We should at some point begin to integrate with popular frameworks, so we'll automatically migrate/rollback the database as necessary, but currently you'll have to do it yourself. Any suggestions on frameworks would be great.

  For AppHarbor, we're using the `SchemaUpdate` feature in NHibernate, which will create any missing entities in the database when we're initializing our repository...