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

[Nathaniel S. H. Brown]

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_forms_with_a_tab
le_less_model

-Nb

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Nathaniel S. H. Brown                           http://nshb.net 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 

> -----Original Message-----
> From: rails-core-bounces at lists.rubyonrails.org 
> [mailto:rails-core-bounces at lists.rubyonrails.org] On Behalf 
> Of Kevin Clark
> Sent: February 13, 2006 8:16 PM
> To: rails-core at lists.rubyonrails.org
> 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 <drernie at opendarwin.org> 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
> > Rails-core at lists.rubyonrails.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails-core
> >
>