On Feb 25, 5:28 pm, "Jeremy Kemper" <[EMAIL PROTECTED]> wrote:
> On 2/25/07, zdennis <[EMAIL PROTECTED]> wrote:
>
> > On Feb 24, 7:44 pm, "Michael Koziarski" <[EMAIL PROTECTED]> wrote:
> > > > 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
> > statements
> > - 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 ).
>
> include Feature
> include AnotherFeature
>
> 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
def some_method
....
end
end
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.
[snip]
>
> 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
>
> > contribute.
>
> 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.
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
-~----------~----~----~----~------~----~------~--~---
