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.
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@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@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core >_______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
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@lists.rubyonrails.org > [mailto:rails-core-bounces@lists.rubyonrails.org] On Behalf > Of Kevin Clark > Sent: February 13, 2006 8:16 PM > To: rails-core@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@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@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails-core > > >
Rick Olson rather :) -Nb ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Nathaniel S. H. Brown http://nshb.net ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> -----Original Message----- > From: rails-core-bounces@lists.rubyonrails.org > [mailto:rails-core-bounces@lists.rubyonrails.org] On Behalf > Of Nathaniel S. H. Brown > Sent: February 13, 2006 8:29 PM > To: k1clark@ucsd.edu; rails-core@lists.rubyonrails.org > 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: rails-core-bounces@lists.rubyonrails.org > > [mailto:rails-core-bounces@lists.rubyonrails.org] On Behalf > Of Kevin > > Clark > > Sent: February 13, 2006 8:16 PM > > To: rails-core@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@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@lists.rubyonrails.org > > > http://lists.rubyonrails.org/mailman/listinfo/rails-core > > > > > > > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core >
> 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:Hey Ernie, The main problem with a large scale refactoring like this is the havoc that it brings to people''s plugins and other people who make use of our implementation methods. It''s one of the reasons we can''t change ActiveRecord::Base#quote to something that''s less likely to clash. Perhaps another approach would be to try and refactor the parts of AR which aren''t related to persistence (validation, attributes=, etc.) so they can simply be ''included'' by other persistence mechanisms. Things like Rick''s tableless models, your own core data, a refined active ldap, could really use this. From there we can plan a way forward to make it easier to write custom persistence tools. -- Cheers Koz
Dr. Ernie Prabhakar
2006-Feb-22 21:34 UTC
ActiveData Re: "ActiveRecord" for Non-SQL Data Sources?
Hi Kevin et al,
Thanks very much for the encouragement and advice. Just to
summarize, the best plan appears to be:
a) Create a plugin ("activedata")
http://wiki.rubyonrails.org/rails/pages/HowTosPlugins
b) Define my own module containing my custom classes ("ActiveData")
c) Define a new generic Query object, and test it for backward-
compatibility ("ActiveData::Query")
d) Define subclasses for methods I want to override, e.g.,
* ActiveData::Base << ActiveRecord::Base, for generic queries/
updates
* ActiveData::Adapter <<
ActiveRecord::ConnectionAdapters::AbstractAdapter, to vend Query object
e) Implement the CoreData adaptor and query, as a separate subclass
(module?)
f) Write unit tests validating all the above
And if this all works, then we can discuss whether it makes sense to
refactor parts of ActiveRecord (perhaps for Rails 2.0) -- but right
now that would be premature.
Is that an accurate summary? Any other suggestions/advice/links/
warnings?
Thanks,
-- Ernie P.
On Feb 13, 2006, at 8:16 PM, Kevin Clark wrote:
> 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 Feb 13, 2006, at 8:28 PM, Nathaniel S. H. Brown
wrote:> 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
On Feb 14, 2006, at 1:12 PM, Michael Koziarski wrote:> The main problem with a large scale refactoring like this is the havoc
> that it brings to people''s plugins and other people who make use
of
> our implementation methods. It''s one of the reasons we
can''t change
> ActiveRecord::Base#quote to something that''s less likely to clash.
>
> Perhaps another approach would be to try and refactor the parts of AR
> which aren''t related to persistence (validation, attributes=,
etc.) so
> they can simply be ''included'' by other persistence
mechanisms.
>
> Things like Rick''s tableless models, your own core data, a
refined
> active ldap, could really use this. From there we can plan a way
> forward to make it easier to write custom persistence tools.
> http://lists.rubyonrails.org/mailman/listinfo/rails-core