> > > Following up on Koz's suggestion to discuss how plugin developers are
> > > monkey patching AR, I'd like to share some of things my coworkers and
> > > I have done.
> > Calling all plugin authors. If you've been frustrated when adding
> > functionality to Active Record, speak here, or forever ... yeah
> Things I think I've nicely monkeypatched...
> - adding temporary table support
> - adding query support for regular expressions, and having better
> hash support (adding prefix and suffix based modifies, ie: field_like
> or field_contains or matches_field)
> - adding efficient mass import functionality for MySQL (PostgreSQL
> 8.2 support is coming as well) for handling multiple value insert
> - adding fulltext index searching support for MySQL
> - adding block based foreign key enable/disable support
> - adding to_csv support which supports has_one, belongs_to and
> has_many relationships
> - adding custom query object support using duck typing and to_sql
> I'd like to see all SQL generation moved into components which are
> registered for one or more adapters. I would like to see
> AbstractAdapter be registered for all of the common queries which are
> handled by all adapters ( LIKE, BETWEEN, etc ).
I really don't see the need for this complexity.
This depends on how things are implemented. I think we need to avoid
implicitly encouraging people doing things like:
class MyAdapter < AbstractAdapter
alias :some_method :some_method_orig
If we can avoid that then I'll all for it, but if that's how we're
relying on mixins to provide additional functionality I think we can
come up with a better way.
Again, the 'registering components' bit seems very strange to me. It's not
solving any problems IMO.
For me it's more greatly decoupling query generation from
ActiveRecord::Base and actual adapter implementation.
I think a stable interface and plugins are all you need.
My last request is that it is easier and more inviting for people to
Now that's wide open Is it hard or uninviting?
I think it could be easier. For me it'd be nice to give some developer
some simple rules like:
- create class
- implement "process_query" method that takes x arguments
- return SQL string or nil
- register class for the adapters that support it's SQL syntax
It completely avoids having people go read through AR source to find
out what sanitize_sql and quote_attribute_conditions, etc.. methods
do. Rather then don't have to care about implementation, they can
rather focus on the functionality they want.