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._______________________________________________
Rails-core mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails-core
