On Feb 25, 5:21 pm, "Jeremy Kemper" <[EMAIL PROTECTED]> wrote: > 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?
Includes are going to include the functionality within the adapter and override methods (or cause infinite alias loops). There are cases when you need to do this, but I don't think every additional include of new query support needs to alias and reimplement sanitize_sql or like methods. Registering query support (aka: RegexpQuery) isolates the overall affect new query support/functionality would have. I am thinking of an 90/10 rule here. Perhaps I am wrong though i my thinking. > > > 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? Take regular expressions for example. Most database engines support them, but they all have syntactically different ways to be expressed in an SQL statement. I don't want to alias/reimplement methods that I shouldn't have to just to get the functionality. I think aliasing is a powerful feature of ruby, but I do not think it is always the best way to go for having people add SQL functionality to AR. What are you thinking here in terms of how to allow users to add support for things like Regexps? [snip] > > 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. This sounds like a good idea. Can you guys expand on this more for how it'd handle queries in practice? 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 -~----------~----~----~----~------~----~------~--~---
