Thanks James. It re-assures me making the Rails app responsible for db changes is the go. I feel I'll have an interesting time to config the CI server to handle builds and deployment later on down the track ... my brain isn't functioning anymore ... that'll be a thing to think about tomorrow :)
On Wednesday, 1 August 2012 23:43:40 UTC+10, James Healy wrote: > > I once worked on a django (!) project that operated in the same way. > > It was an old PHP app that was slowly being ported to python - from the > users point of view it was one app. > > We decided that only django could modify and manage the DB schema - even > tables exclusively used by PHP. It worked quite well once everyone wrapped > their head around the agreed protocol. > > James > On Aug 1, 2012 11:23 PM, "Chris Corbyn" <[email protected]> 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 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/-/P8ycDj3kfrUJ. 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.
