Re: [rails-oceania] One database - multiple applications

[Pat Allan]

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 rails-...@googlegroups.com.
> To unsubscribe from this group, send email to rails-oceani...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.

[Chris Corbyn]

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.

[James Healy]

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

[Tim Uckun]

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.

[fresh...@gmail.com]

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.

--
James

[Simon Russell]

The separate app sounds a little painful to me. Normally I'd agree,
but it does mean that a lot of the Rails conveniences won't be
working. Or there'll be some hacking to make them work.

Is the Perl developer using something similar to Rails migrations
already? Who's going to be doing most of the DB changes?