On Feb 23, 3:59 pm, "Michael Koziarski" <[EMAIL PROTECTED]> wrote:
[snip] > 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 [1] > > > 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 > 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. > 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. > > 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. Zach --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
