Just to be clear, you are using datamapper which does not require the use of migrations, but you can include a dependency to 'dm-migrations' and create the migrations yourself.
Also, I am pretty sure you can create a custom remote_task in capistrano that could do the auto migration for you. Michael On 12/31/08, MarkMT <[email protected]> wrote: > > Thanks gents... returning to this after a couple of days traveling... > It looks like differences in versions between bundled and production > system gems were indeed the cause of my problem. I remain a little > unclear though about exactly what the respective roles of bundled and > system gems are in the deployment platform. > > I had a few other obstacles to get over before before I was able to > declare success. In case anyone else should trip up on these... > > - I was missing the launchy and do_mysql gems on my production > platform. I have no idea what launchy does, but discovered I needed it > by running merb with the --verbose option (found some advice here: > http://sandbox.manning.com/thread.jspa?threadID=27760&tstart=0). > - I had an additional problem installing do_mysql because I didn't > have the libmysqlclient15-dev library on my slicehost production > machine (ubuntu hardy), and initially the package manager had trouble > finding it in the repository. It turned out that I had to update my > platform ('sudo aptitude update' and 'sudo aptitude upgrade') before I > was able to run 'sudo aptitude install libmysqlclient15-dev'. I was > then able to run 'sudo gem install do_mysql'. > - I had to run "rake MERB_ENV='production' db:automigrate" manually > on the production machine. Maybe it's obvious that this has to be > done, but afaik it isn't mentioned in anything I've read about > deployment. Seems (to my perhaps naive mind) like the kind of thing > that could be handled by Capistrano. 'cap deploy:cold" does do a > migrate, but if I understand correctly that only handles explicit > migrations, a la Rails, and so won't do anything to create db tables > for your merb models. > - I'm not absolutely certain that the following was necessary... it's > conceivably an artifact of the db connection problem I had before > automigrating, but I also had to add "host: 'localhost'" to the > production database definition in database.yml. > > > Mark. > > > > On Dec 30, 12:29 pm, tonyc <[email protected]> wrote: >> On Dec 26, 7:04 pm, Roy Wright <[email protected]> wrote: >> >> > On Dec 26, 2008, at 6:30 PM, MarkMT wrote: >> >> > > /usr/local/lib/site_ruby/1.8/rubygems.rb:149:in `activate': can't >> > > activate data_objects (= 0.9.9, runtime), already activated >> > > data_objects-0.9.10 (Gem::Exception) >> >> > I've seen something similar where the system gems were updated >> > to a later version than in the merb apps dependencies. I think the >> > solution is to run "thor merb:gem:install" to cache the versions as >> > specified in dependency.rb. >> >> Yep, this is what it sounds like. You could probably just bump the >> version of data_objects up in your dependencies.rb file, and it seems >> like it should work. >> >> Incidentally, I've just done a little writeup on deploying a bundled >> Merb app on Passenger to an Ubuntu box (mine are on slicehost, too): >> >> http://weblog.halogenlabs.com/articles/the-super-easy-guide-to-deploy... >> >> There are some capistrano tasks that will handle the rebundling before >> a restart of your app server, too... feedback on the article is >> welcome! >> >> - Tony > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "merb" 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/merb?hl=en -~----------~----~----~----~------~----~------~--~---
