[Rails-core] "ActiveRecord" for Non-SQL Data Sources?

[Dr. Ernie Prabhakar]

Hi all,

I'm trying to do something a wee bit crazy, and would love to get  
your combined wisdom on how to proceed.  I've looking at ways to get  
Rails working with Mac OS X's CoreData framework:

http://www.opendarwin.org/~drernie/B2126242314/C499496031/ 
E20051019100520/index.html

When I asked DHH about Active Record, he replied:

On Jan 3, 2006, at 9:04 PM, David Heinemeier Hansson wrote:
> Active Record is very deeply tied to SQL. By design. Non-SQL data  
> sources should just create their own AR-flavored framework. See  
> ActiveLDAP as an example: http://rubyforge.org/projects/ruby- 
> activeldap/

So, I looked at ActiveLDAP, and was rather disappointed.  Not as a  
criticism of them, but compared to ActiveRecord it didn't have all  
the bells-and-whistles I was looking for, such as:

• conventions for automatically mapping classes onto back-end entities
• flexible method names for accessing attributes
• dynamically-loaded adapter plug-ins for various datastores

After trying various options (such as cut-and-paste and refactoring),  
I reluctantly concluded that the simplest way to achieve my goal  
would be to simply replace the SQL portions of ActiveRecord with a  
more general "query" mechanism:

http://www.opendarwin.org/~drernie/B2126242314/C499496031/ 
E20060105103606/index.html

Of course, this solution is itself problematic.  The simplest  
solution (copy and then cut) would result in my duplicating huge  
amounts of ActiveRecord code -- which I understand poorly, and would  
surely bitrot.

The only alternative, it would seem, would be to abstract away the  
SQL dependence of ActiveRecord -- the very thing DHH warned  
against.   So, despite full knowledge that "fools rush in where  
angels fear to tread", I decided to give it a shot, to at least  
estimate the difficulty. The results are here:

http://www.opendarwin.org/~drernie/src/ActiveRecord-nonSQL.zip

I have to say, it actually wasn't all that bad. There's only a finite  
set of methods that actually generate SQL, which I changed to operate  
on a generic "query" object. There's some subtleties involved in how  
to handle quoting, and of course app-generated SQL would only work  
with an SQL-based adapter, but (at least for me) that would be an  
acceptable tradeoff.  As a side-benefit, it seems to me that this  
might actually simplify the development of adaptors, while still  
maintaining backward compatibility.

Of course, if people actively override the affected methods to change  
the semantics and regenerate SQL, such patches would become horribly  
broken, which means this proposal would be dead in the water.  But  
perhaps it is anyway.

That's why I'm asking, to see how people feel about this approach,  
and find out whether there's a better way to achieve my goals, or  
whether I just have to scale back my ambitions.

Thanks,
-- Ernie P.