While you can already do something like this with
execute in your migrations:
execute("CREATE VIEW my_tasty_snacks AS SELECT * FROM snacks WHERE food = 'Tasty';")
With RailsOnPage, you’re provided a DSL so that you can do the following:
create_view :my_tasy_snacks do |view| view.select '*' view.from 'snacks' view.conditions 'food' => 'Tasty' end
note: I haven’t tested the above, just a hypothetical example
Anyhow, if you’re in the habit of using views, functions, or triggers with your PostgreSQL database and are using Ruby on Rails, you might give RailsOnPg a whirl.
We have a client that already has some database replication going on in their deployment and needed to have most of their Ruby on Rails application pull from slave servers, but the few writes would go to the master, which would then end up in their slaves.
So, I was able to quickly extend ActiveRecord with just two methods to achieve this. Anyhow, earlier today, someone in #caboose asked if there was any solutions to this and it prompted me to finally package this up into a quick and dirty Rails plugin.
Introducing… Active Delegate!
To install, do the following:
cd vendor/plugins; piston import http://svn.planetargon.org/rails/plugins/active_delegate
Next, you’ll need to create another database entry in your
login: &login adapter: postgresql host: localhost port: 5432 development: database: rubyurl_development <<: *login test: database: rubyurl_test <<: *login production: database: rubyurl_servant <<: *login # NOTICE THE NEXT ENTRY/KEY master_database: database: rubyurl_master <<: *login
At this point, your Rails application won’t talk to the
master_database, because nothing is being told to connect to it. So, the current solution with Active Delegate is to create an ActiveRecord model that will act as a connection handler.
# app/models/master_database.rb class MasterDatabase < ActiveRecord::Base handles_connection_for :master_database # <-- this matches the key from our database.yml end
Now, in the model(s) that we’ll want to have talk to this database, we’ll do add the following.
# app/models/animal.rb class Animal < ActiveRecord::Base delegates_connection_to :master_database, :on => [:create, :save, :destroy] end
Now, when your application performs a
destroy, it’ll talk to the master database and your
find calls will retrieve data from your servant database.
It’s late on a Friday afternoon and I felt compelled to toss this up for everyone. I think that this could be improved quite a bit, but it’s working great for the original problem that needed to be solved.
If you have feedback and/or bugs, please send us tickets.
As promised, I wanted to post some the slides from my talk today.
A few weeks ago, I announced the Ruby on Rails Legacy mailing list, which I also talked about in my talk. I invite you all to stop by and ask questions… and help the community grow.
If there was one thing that I wanted to really express in my talk… it was that you’re not alone. You’re not the only one faced with a situation where you need to work around legacy conventions, opinions, and politics.
...you’re… not… alone. ;-)
Heading out to go see James Adam talk about plugins… !
5 comments Latest by mikael Gyde Møller Sat, 24 Jun 2006 20:24:03 GMT
Rails and Database Schemas
This morning, David Thomas opened up the conference by pointing out three problems that Rails needs to solve. The one that hit home for me and my love of databases… especially monolithic legacy ones… was his first bullet, “Data Integration.” Natural keys, composites, automatic AR relationships with reflection, and non-database backends. He didn’t mention stored procedures… I’ll have to ask him about that. ;-)
Shared Hosting and Rails
I’m currently sitting in Topfunky’s talk, “Rails Deployment on Shared Hosting”. He had a few funny slides… yes… deployment on shared hosting can be painful. We’ve been working with our customers to ease this problem as much as possible by collaborating on the PLANET ARGON Documentation Project. He also suggested that people consider a VPS, which is a very viable option… if you have the time and patience to setup the server. The pains of regular shared hosting are a big concern especially if you have a mission critical business application. This is why we moved towards our Rails Business Hosting plans and are working out the details for yet another step above in terms of cost and reliability. Stay tuned for more details…
I’ll post more notes later…
9 comments Latest by Joe Wed, 26 Apr 2006 10:01:52 GMT
Last week, I gave a live presentation to ~250 people, which was basically me walking through the process of using Ruby on Rails to talk to a legacy database1. For my example, I used the Dell DVD database... the PostgreSQL version. You can review some comments about my presentation by reviewing this entry on the blog of Ryan Davis. I wrapped quite a bit of the database in a few minutes and then showed what another 45 minutes of work could do with Rails. I’ll tarball that code and post it online soon.
Alex Bunardzic found it practical. I’ll take that as a compliment. ;-)
Earlier, I noticed this blog entry by Chris… where he said, “PostgreSQL also seems to be growing more briskly among the database category, while MySQL declines modestly. I guess that’s good news for Robby.” What exactly made me happy? This bullet made by Tim O’Reilly on Radar in his post, State of the Computer Book Market, Part 2.
“A surprise to many may be the strong growth of PostgreSQL, up 84% over a year ago. We’ve also been hearing some signs of growth in the Postgres market from our “alpha geek” radar, with reasons given including better support for geo data, and better handling of very large data sets. New companies like Greenplum and EnterpriseDB have also brought a little focus to this market. We’re updating our PostgreSQL book, and watching this market closely.”
That’s awesome! Go PostgreSQL!
Then to my surprise, I was contacted by CRN (again) to get my thoughts on MySQL’s awesome storage-engine plugin system... which showed up a few hours later in this article. The writer of that article managed to goof my last name (Robby Hill?)... and hopefully that gets resolved soon. ;-)
As I said at Canada on Rails in front of 250 people, “I find databases… sexy.”
(free desktop wallpaper!)
Why Rails? Why PostgreSQL?
Rails.. that’s a no-brainer.
PostgreSQL? Well.. they have compatible licenses… no dual-license smell when your trying to sell your application as a complete solution… and as Rails is database agnostic... there is no reason not to give PostgreSQL a try.
Who uses PostgreSQL on Rails?
If your using PostgreSQL on Rails… email me... I’d love to hear and share your story on my O’Reilly blog, like I did with Derek Sivers and Jeremy Kemper of CDBaby a few months ago, which you can read here.
again… I find databases sexy...
1 According to the Rails convention (and by me)... any database created pre-Rails or doesn’t follow the conventions is considered legacy. ;-)
1 comment Latest by Frederick Ros Wed, 12 Apr 2006 05:14:01 GMT
To avoid feeling like I have neglected my blog lately… I wanted to point out a few things.
First of all… there is a nice new book that was sitting at Powells technical bookstore just a few hours ago… and is now sitting on my desk. I read a few pages on the bus ride home today of Refactoring Database: Evolutionary Database Design. It’s a Martin Fowler signature book and you can read more by Scott W. Ambler (one of the authors) at Agile Data. So far it seems like a good book if you’re into database schemas and if your a fan of the Refactoring scene. :-)
In other news… Jeremy and I are preparing for our journey up to Vancouver, B.C. this week. Jeremy will be presenting his talk about i18n and Ruby on Rails… and I’ll be presenting my talk about using Ruby on Rails with Legacy databases. I look forward to meeting those of you who are making the trip to Canada on Rails (which is sold-out!) and if you don’t catch us there… we will also be presenting at RailsConf 2006!
If you’re going to be in Vancouver this week and would like to meet us for some drinks, hacking, or whatever… stop by on #canadaonrails (irc.freenode.net) and let us know. :-)
Older posts: 1 2