Rick Olson rather :) -Nb
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Nathaniel S. H. Brown http://nshb.net ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Nathaniel S. H. Brown > Sent: February 13, 2006 8:29 PM > To: [EMAIL PROTECTED]; [email protected] > Subject: RE: [Rails-core] "ActiveRecord" for Non-SQL Data Sources? > > This seems a little OT, but you might find it useful. > > Emil Marceta, a local Ruby guy here in Vancouver wrote this > post to the vanruby.com mailing list. > > http://lists.vanruby.com/pipermail/discuss/2006-January/000050.html > > It describes how to use ActiveRecord's validations against > table-less data model based on Rick Olsen's code here: > > http://rails.techno-weenie.net/tip/2005/11/19/validate_your_fo > rms_with_a_tab > le_less_model > > -Nb > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Nathaniel S. H. Brown http://nshb.net > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf > Of Kevin > > Clark > > Sent: February 13, 2006 8:16 PM > > To: [email protected] > > Subject: Re: [Rails-core] "ActiveRecord" for Non-SQL Data Sources? > > > > 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 > _______________________________________________ Rails-core mailing list [email protected] http://lists.rubyonrails.org/mailman/listinfo/rails-core
