We've spoken about this several times in the past, and it's still one
of our goals for the rails 2.0 release. The query generation code
is kinda ugly, and frankly a lot of it is in the wrong place.
We should be generating the queries inside the adapters, that way we
can just use polymorphism to provide adapter specific behaviour.
There seems to be two ways to handle query generation which are better
then the existing methods.
1 - Generate queries inside the adapters
2 - Register queries to be associated with certain adapters.
Currently I prefer #2 because it allows you to have only one spot
where a particular query is generated and you can associate (register)
that query with one or more database adapters. #1 all by itself makes
sense, but since some db vendors do support the same semantics for
certain functions or queries you should be able to support DRY for
those overlapping queries. I also like #2 better because you can
simlply add a supported adapter once it has been tested.
For example, let's say I register RegexpQuerySupport which currently
has been tested on MySQL.
register RegexpQuerySupport, :adapters=>:mysql
Now if you download it and test it against PostgreSQL by changing
":mysql" to "[ :mysql, :postgresql ]" and it works, that's the all
effort involved. If it didn't work, you could write a
RegexpQuerySupport object inside the PostgreSQL adapter and register
it for :postgresql.
> Alot of what I'd like to do is very similar to my approach with better
> finder support in ActiveRecord::Extensions 
> Since now is the time that alot of changes are happening for Rails
> 2.0... what's the core groups feedback on making query support for
> ActiveRecord more modular.
What do you mean 'more modular', what are the specific problems
I think query generation should be separated from ActiveRecord::Base.
Right now to add custom query support you have to hardcode a method/
query, or you have to override ActiveRecord::Base methods like
sanitize_sql, quote to get it to work across the board depending on
the functionality you're adding. The query support for ActiveRecord
should be more modular so adding a new query won't necessarily break
other code in ActiveRecord. Given this making the query support more
component driven also isolates and limits the ripple effect that
people's plugins would cause.
I think there's probably a place for adding some
stable APIs to make some common-customisations easier. So long as it
doesn't materially impact the complexity of ActiveRecord, or the
performance of it, then I think everyone wins when plugins don't need
to break every release.
Implementing a behavioral pattern similar to chain of responsibility
seems to be a good route. I use this in ActiveRecord::Extensions and
so far it's worked great. If you happen to pull down the source 
look in th extensions.rb file and check out how the MySQL, PostgreSQL
and Sqlite regular expression support is handled.
Perhaps we need to get a thread going with AR plugin authors, see what
stuff they're monkeypatching, find a few common cases, and build an
That sounds like a great idea.
There could be and there probably is a better way to handle this query
generation in ActiveRecord, I look forward to seeing what everyone can
come up with together.