Dennis-
I've been thinking of this for a while. At least, if I'm reading what
you're saying right, I have.
To me, this is what I've wanted.
Any object that implements .to_sql(connection) should be allowed as a condition.
#A useless stub example.
class Array
def to_sql(connection)
connection.quote(self.to_s)
end
end
Basically, this would open up any crazy-idea that anyone wants to
implement for conditions.
ActiveSupport would implement the default Object#to_sql(con) methods.
Thoughts on this API?
-hampton.
On 11/7/06, zdennis <[EMAIL PROTECTED]> wrote:
>
> ActiveRecord has a limitation for finder support. In order to extend it
> you have to either muck up ActiveRecord, a database adapter or you end
> up creating an extension that aliases all of the find, sanitize_sql,
> attribute_conditions, etc. methods.
>
> I've been working the past few weeks on pulling out finder support into
> Extensions, which decouples it from AR core code, and allows there to be
> more flexibility with finder support.
>
> The whole idea of moving finder support into a set of command extensions
> is to implement the Chain Of Responsibility[0] design pattern for
> processing find conditions that are given as a Hash.
>
> I briefly posted on this the other week[1] with an example of how I make
> Ranges work.
>
> The benefits I see of this are the following:
> - decouple finder support in AR from AR core (promote loose coupling)
> - allows developers who want to extend AR finder support to do so
> without redefining parts of AR core
> - allows developers to use any core/stdlib class in Ruby or any user
> defined class to aide in special searching support
> - lowers the barrier for developers who want to write extensions for
> finders
> - allows developers to write finder extensions to enhance support for
> more database vendor functionality.
> - simplifies the process for enhancing finder support in AR which
> reduces the chance that someone will inadvertently break other AR
> functionality
>
> Some examples of this are allowing things like:
>
> Model.find( :all, :conditions=>{ :name=>'Zach' } )
> Model.find( :all, :conditions=>{ :name=> [ 'Zach', 'John', Doug' ] } )
> Model.find( :all, :conditions=>{ :name=> /Zach|John|Doug/ } )
> Model.find( :all, :conditions=>{ :number=> (0..100) } )
> Model.find(:all,:conditions=>{:created_on=>(Date.today..Date.today-30 })
> Model.find( :all, :conditions=>{ :description_contains=>'Good' } )
> Model.find( :all, :conditions=>{ :description_starts_with=>'Good' } )
> Model.find( :all, :conditions=>{ :description=>UserCreatedObject.new })
>
> I am not advocating that all enhancements to finder support would go in
> core, but if the Extensions implemented using the Chain Of
> Responsibility pattern is in core it will allow developers to enrich
> plugins/extensions for Oracle, MySQL or PostgreSQL (or any other db
> adapter) support with a lower barrier of entry, and lower chance of
> breaking any other part of AR.
>
> I'm a MySQL guy right now, slowly picking up PostgreSQL. I'm looking for
> people who are PostgreSQL, MS SQL, Oracle, etc users who would be
> interested in setting up automated (or manual) testing to help get all
> of AR's tests passing with this functionality, so this can be offered as
> a patch to AR.
>
> Zach
> http://www.continuousthinking.com
>
>
> [0] http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern
> [1]
> http://www.continuousthinking.com/are/finder-extensions-and-mysql-fulltext-indexes
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
