Hi Chris, The Rails app I'm writing will be the one exposed to the clients (well ... not really ... it gets quite complicated to paint the whole picture, the Rails app will be called up by "ruote" workflow participants ...)
The Perl app has to be there ... because of typical reasons ... legacy perl codebase + perl expertise of the developer who's implementing those particular features On Wednesday, 1 August 2012 23:18:08 UTC+10, Chris Corbyn wrote: > > We run a Rails app which talks to the same database as a PHP app. For a > while, we wrote migrations in whichever application the migration was > targeted at, but eventually we decided it was better just to do all of our > migrations in Rails, regardless of whether or not Rails will be touching > that part of the schema (it will eventually, as we're progressively > migrating our entire codebase). We always deploy both apps simultaneously > anyway, so this just makes for a more consistent deployment/migration > process. > > Do you have two apps that act as a single app from the end user's > perspective, or just two related apps that access the same database? > Curious, since I haven't bumped into anybody else doing what we're doing > just yet. > > > Il giorno 01/ago/2012, alle ore 22:59, Pat Allan ha scritto: > > > I'd probably put it all in Rails migrations, so at least there's > consistency and a single point of truth. Otherwise, you may end up with > code in one place making one change, and then code in another - unaware of > those changes - try to do the same thing, or try something now impossible. > > > > Granted, I'd prefer just to avoid the situation completely and have it > all one app, one language, one framework. > > > > -- > > Pat > > > > On 01/08/2012, at 2:48 PM, marsbomber 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. > > > > -- 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/-/bucRYmVA6ucJ. 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.
