Forum: Ruby on Rails Can two Rails versions use one database?

0e928fb508e3f2eb17eaefa9d2e271f4?d=identicon&s=25 Russ Dast (dast)
on 2014-01-30 22:51
(Received via mailing list)
I'm working on a Rails 1 application. We'd like to upgrade it to Rails 3
or
4, but Rails 1 is so old that we think it would take a total rewrite to
upgrade. There are management and budget issues with a total rewrite. We
wouldn't be able to deliver anything until the entire rewritten
application
was finished.

So, we are searching for creative solutions to the upgrade problem. One
idea is to start rewriting the application in Rails 4 and run it
alongside
the Rails 1 application. As features are added to the Rails 4 version,
the
same feature in the Rails 1 version could be taken offline. Users would
see
a mix of the two versions. Some pages would be served by Rails 1 and
others
by Rails 4.

This would require both the Rails 1 and Rails 4 versions to use the same
database.

So my question is, will this work? What problems with this approach
should
we be anticipating? We know it isn't a perfect solution, but we're
hoping
it's good enough to drive the project forward.
A47e0a6beeb9d048ff054fc1c3a97418?d=identicon&s=25 Walter Davis (walterdavis)
on 2014-01-30 23:15
(Received via mailing list)
You may want to watch this talk, from last year's Railsconf.
https://www.youtube.com/watch?v=xi7z-vGNNGw Now this isn't moving quite
as far as you want to go, but it still might be instructional.

Walter
17c1d72be21a2a43be717c6dc1660c7b?d=identicon&s=25 Jim (Guest)
on 2014-01-31 14:12
(Received via mailing list)
On Thursday, January 30, 2014 4:13:58 PM UTC-5, Russ S wrote:

> So my question is, will this work? What problems with this approach should
> we be anticipating? We know it isn't a perfect solution, but we're hoping
> it's good enough to drive the project forward.
>

The thing to consider most carefully is how you will be able to run the
single website from two different rails apps.  Things like linking
between
them, sharing authentication, session variables like session and flash,
stuff like that.  Databases are inherently multi-user systems so you're
not
so likely to run into problems with the database itself unless you are
using sqlite, although I'm not so familiar with Rails 1 ActiveRecord
mechanisms anymore.
0e928fb508e3f2eb17eaefa9d2e271f4?d=identicon&s=25 Russ Dast (dast)
on 2014-02-05 17:53
(Received via mailing list)
Thanks Walter and Jim for your feedback. The Railsconf talk was indeed
informative, although we are still leaning against an upgrade path and
are
more likely to choose a rewrite-based approach. Jim, I hadn't thought
about
the flash, so thanks for pointing that out. I think we can probably
manage
by limiting flash feedback to one site or the other. We might have to
make
some workflows slightly more complicated for that to work.

Russ
280b78a61a968391b7e07e912be102a8?d=identicon&s=25 Robert Walker (robert4723)
on 2014-02-05 21:10
Russ Dast wrote in post #1135683:
> Thanks Walter and Jim for your feedback. The Railsconf talk was indeed
> informative, although we are still leaning against an upgrade path and
> are
> more likely to choose a rewrite-based approach. Jim, I hadn't thought
> about
> the flash, so thanks for pointing that out. I think we can probably
> manage
> by limiting flash feedback to one site or the other. We might have to
> make
> some workflows slightly more complicated for that to work.

I think the point was you'll need to deal with session sharing as a
whole. The flash is really just stored in the session anyway, so if you
solve the session issue then you solve the flash issue along with it.
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.