Ernie, I think it is great that you were able to modify ActiveRecord for you needs. You might want to pull your changes into a plugin where others could easily use your new code. That being said, I don't think something like this would go well in core. Plugins were created exactly for this situation though, so all is well. Kev
On 2/13/06, Dr. Ernie Prabhakar <[EMAIL PROTECTED]> wrote: > 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 >
_______________________________________________ Rails-core mailing list [email protected] http://lists.rubyonrails.org/mailman/listinfo/rails-core
