I would consider having a separate app handling the db migration if the Rails app and Perl app are considered equal... but they are not ... the perl app will be hidden behind the rails app. And strategically, if I keep the db migration inside the rails app, I may get more bargaining power down the line to scrap the perl codebase and merge all those logic into the rails one :) playing evil here LOL
On Thursday, 2 August 2012 09:20:26 UTC+10, freshtonic wrote: > > I also favour this approach. > > My first encounter with Ruby & ActiveRecord was exactly this. In 2006 > I worked for a company with a suite of Java applications sitting on > top of a common database, which was managed with hand-rolled raw SQL > scripts. > > One of our sysadmins suggested we use ActiveRecord migrations to > manage the schema and we never looked back. (It was also how I ended > up getting into Ruby & Rails - and I never took another Java role). > > -- James. > > On 2 August 2012 09:05, Tim Uckun <[email protected]> wrote: > > Personally I would create a separate app just for the migrations. This > > will force you to use that app and will make it clear multiple apps > > are using the database structure. > > > > > > > > On Thu, Aug 2, 2012 at 12:48 AM, marsbomber <[email protected]> wrote: > >> Hi guys, > >> > >> I'd love to get your ideas on how to manage a database if it's used by > >> multiple applications. > >> > >> Here's the scenario. A MySQL database will be used by 2 separate > >> applications, one written in Ruby/Rails, the other written in Perl. > >> > >> Let's say there're 5 tables in the db, "one", "two", "three", "four" > and > >> "five". The Rails app uses 3 tables "one", "two" and "three". The Perl > app > >> uses "three", "four" and "five". > >> > >> Rails can handle "one", "two", "three" using db migration. > >> - Should it handle table creation/migration for "four" and "five"? > >> - What about table "three"? If the Perl app needs to add extra columns > for > >> its own purpose, should the changes be done using the Rails db migrate? > >> - What's the best approach to make the WHOLE database scriptable, > >> versionable and CI-buildable? > >> > >> Thanks, > >> Jim > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "Ruby or Rails Oceania" group. > >> To view this discussion on the web visit > >> https://groups.google.com/d/msg/rails-oceania/-/A4ka74XblcYJ. > >> 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/rails-oceania?hl=en. > > > > -- > > You received this message because you are subscribed to the Google > Groups "Ruby or Rails Oceania" 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/rails-oceania?hl=en. > > > > > > -- > James > -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To view this discussion on the web visit https://groups.google.com/d/msg/rails-oceania/-/JKtJx027AEUJ. 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/rails-oceania?hl=en.
