Il giorno 03/giu/2012, alle ore 15.17, Ken Collins ha scritto:
>
> On Jun 3, 2012, at 7:35 AM, Andrew White wrote:
>
>> At some point (I don't know when) it was decided that rather than
>> constructing SQL out of string fragments, Rails 3 would use Arel to build
>> SQL but with a separate query interface that maintained backwards
>> compatibility but added functionality (ActiveRecord::Relation). However
>> because Arel was already quite well known by that point some people got the
>> wrong end of the stick, especially with the protracted development of Rails
>> 3.
>
>
> Coming from the perspective of an ActiveRecord adapter like SQL Server, I
> wish that both ActiveRecord and plugins alike used Arel more heavily. I know
> this is a doubled edged sword. You want end users of the framework to stay as
> high level as possible and not dip down to Arel. However, I see a need to
> expose Arel more for plugin developers to stop constructing SQL fragments
> from strings.
>
> The biggest pain from my perspective are order strings and select fragments.
> The SQL Server adapter's visitor needs to leverage real Arel ordering nodes
> since the visitor will have to eventually remove duplicates as TSQL does not
> allow "ORDER BY foo ASC, foo DESC".
>
> Other issues always come back to the way our adapter has to handle LIMIT and
> OFFSET using a paging function like ROW_NUMBER(). When plugin authors even
> use basic of SQL fragments like a SELECT... vs projections, it means we have
> to end up doing the parsing instead as we have to re-compose a complex
> statement to work with our window functions.
>
> The way I see, the more ActiveRecord and its plugins use Arel, the better off
> other adapters and engines can make decisions lower down the stack. I hope
> Rails core considers this as we move forward.
If a similar problem exists I purpose instead the adoption of a middle layer of
abstraction for common complex queries in a way similar to what built-in
helpers are for views.
A very stupid API stub could be like that
module ASetOfCommonComplexQueries
def a_very_common_complex_query(*params)
# .... Use a lot of AREL here
# then return an ActiveRecord::Relation
end
end
It's just an example, you can probably do much better
This layer could also provide the necessary abstraction to these queries that
for some reason depends on a particular database:
module Pg::ASetOfCommonComplexQueries
def a_very_common_complex_query(*params)
# a_very_common_complex_query implemented with pg related features
end
end
module Mysql::ASetOfCommonComplexQueries
def a_very_common_complex_query(*params)
# a_very_common_complex_query implemented with mysql related features
end
end
Obviously these implementations are responsibilities for adapters more than for
Rails but a common convenience API could be a way to approach the problem.
I really dislike the idea that client code should depend on an implementative
component.
Maurizio
--
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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
