Blog posts tagged "abstraction"

Rails, Data Models, and find_by_sql

March 24th, 2005

Did a little more hacking on Recipes on Rails yesterday. Haven’t decided if I’m doing something wrong, or if ActiveRecord sacrifices a lot of flexibility in the quest for rapid development. I find myself using find_by_sql heavily, which seems wrong. Could be a metaphor clash.

Mental Models and Metaphors

With Enterprise we used a heavily sub-classed DB::DataObject, also an Active Record implementation but with a different metaphor. It doesn’t have AR’s awesome, and brain dead simple declarative association syntax, instead it takes a method oriented approach to query building which allows you to build up a domain model hiearchy where query logic accretes via polymorphism.

The simplest possible example of this is our use of a domainId key in Enterprise which is used to silo and segregate our data (development was primarily targeting ASP deployment). Any DAO which descends from GS::DataObject will automatically insert domainId into the query. In general it meant we could right powerful find methods that were actually very thin wrappers of a parent find, just permutating the query slightly with the addition of a few add conditions (e.g. wheres, sub-queries, left outer joins, whatever).

Caveat

Still very much learning Rails (and Ruby), so take it all with a grain of salt. Maybe there is room for a mix-in somewhere that would refactor away the find_by_sql usage.

The Desperate PHP Hacker

Much of the current evangelism (of which DHH and 37sigs are an amazing, untiring source) seems to have targetted the Java developer community (or perhaps they’re just the most touchy?). Seems like there is a need for a ‘Rails Eye for the PHP Guy’ kind of series. I wonder if my PHP style is too idiosyncratic.

Tagged: Uncategorized , , , , , ,

PEAR::DB and MySQL’s AUTO_INCREMENT Fields

January 31st, 2004

In which our protagonist begins a more thorough exploration of PEAR, and quickly runs into a challenge. Non-PHP hackers should feel free to avert their eyes. Maybe this is a well known hack, maybe (hopefully!) there is a better way to do this, but a quick Google search turned up a deafening silence, a marked dearth, of information on how to access a MySQL insert_id (the value created by inserting a row into a table with an AUTO_INCREMENT column).

I understand that using AUTO_INCREMENT columns is the “wrong” way to do things as far as PEAR is concerned, I’m supposed to use its implemented in PHP sequences, rather then the native and implemented in C method I’ve been using quite happily for years. (If I find myself migrating my MySQL app to Oracle sometime soon, I promise you AUTO_INCREMENT columns are going to be the least of my worries.)

Perl DBI faced a similar dilemma many years ago, and decided, wisely, to punt on the whole issue. They didn’t provide a solution, and they didn’t preclude you from using your native solution. Turns out sometimes doing less is more.

And lastly, when the hell did PHP get so high and holy that it refuses to let me code the way I want to code? Stuff like this constantly turns me off of PEAR, the whole thing just kind of has a bad smell about it.

But enough with the ranting, so here is my current, hold-me-over-until-someone-points-out-the-error-of-my-ways solution.

Your PEAR::DB object $dbh holds a reference to the MySQL connection object in $dbh->connection. Which allows you take a stroll down memory lane to the bad old days with this little gem:

$id = mysql_insert_id($dbh->connection)

For all our veneer of OO civilization, it doesn’t take much to scratch away the surface and expose our naked barbarian PHP soul does it?

Tagged: Uncategorized , , , ,