This post originated from an RSS feed registered with Ruby Buzz
by Obie Fernandez.
Original Post: More Enterprise Rails, Using Legacy Oracle Tables
Feed Title: Obie On Rails (Has It Been 9 Years Already?)
Feed URL: http://jroller.com/obie/feed/entries/rss
Feed Description: Obie Fernandez talks about life as a technologist, mostly as ramblings about software development and consulting. Nowadays it's pretty much all about Ruby and Ruby on Rails.
This is the first installment of what I'm sure will become a popular topic for me over the next few weeks...
So, my "steeldriven" ThoughtWorks team wrapped up our second full week onsite at that bank I mentioned a few entries ago. The first workstream, which Joe and Badri have been putting significant effort into, is the first cut of our domain-specific language (DSL) in Ruby. TDD'ing a DSL is going well and I hope Joe provides some additional comments about it soon. Anyway, this post is not about DSL's -- what it is about is that we started another workstream last week, giving me a chance to do more than just the project management and client relationship tasks that've been otherwise keeping me very busy. Jay and I started work on the web interface that will let product maintainers CRUD the DSL scripts and invoke them to accomplish monthly batch jobs.
Our DSL scripts are per business entity and product (I'm genericizing the concepts here a little bit on purpose, btw) and we need to map to legacy Oracle database schemas that contain that data. Our original strategy was to use "set_table_name" to match the legacy table name and just put up with the dozens of awkwardly named columns. That approach lasted all of 20 minutes once I got hot and heavy into it. I'll elaborate...
First we ran into a Fixtures bug that's been around a while. The Fixtures class does not use the set_table_name directive, so it can't find fixtures data for your tests that use it. Since we do test-first programming (are you?) then we were pretty much stuck.
I was actually aware of this bug from before and after some quick research to determine that it wasn't fixed yet, Jay and I wrote a quick patch. AFAIC it was pretty easy, just tweaking some lines in fixtures.rb within our frozen copy of EdgeRails. Interestingly, in doing research for this blog entry I realized that Kevin Clark submitted a patch for this issue recently, but took the opposite approach that I did to solving the problem. I think mine is somewhat better, particularly since it doesn't require an extra directive in your unit test. Kevin (and perhaps everyone, I don't know) assumes that you must name your fixtures file the same as the table backing your ActiveRecord model. Horrible! Legacy table names usually suck big time -- the less I have to look at those ugly names the better. Let's say you have a Person class that maps to a table named prsn_fct_dt (a dba would have no trouble deciphering that as "Person Fact Data". See what I mean?
I'll put out our patch as a plugin if anyone is interested: we think you'd name your fixtures file: people.yml just like in a normal Rails app. The snippet of Ruby code that makes it work is @class_name.constantize.table_name which takes the class name which is discernible from the filename, looks up the AR class instance using constantize (kind of like Class.forName in Java), and uses the table_name field (the variable set by set_table_name, duh). It worked great, until I decided "screw that I don't want to use those ugly column names either".
It's dinner time, so I guess I'll continue this story at the next opportune moment
Previous Topic
