On 2/25/07, zdennis <[EMAIL PROTECTED]> wrote: > > 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.
How is this different from include RegexpQuery in the adapter? > What do you mean 'more modular', what are the specific problems > > you're hitting? > > 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. Do you have a concrete example? What is 'adding a new query' and does it happen often? > 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 [0] > look in th extensions.rb file and check out how the MySQL, PostgreSQL > and Sqlite regular expression support is handled. This looks like mixing in a module, still. > 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 > > API? > > 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. Me too! I like Ernie's suggestion of a SqlStatement-like object, or even better, settling on some duck-typing conventions for sql-like strings. SqlString < String could also hold its bind variables. The database adapter could translate that to whatever native support for bound parameters, even prepare and cache the statement. jeremy --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
