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. 1.) Truncate. Currently implemented in ActiveWarehouse ETL for MySQL. 2.) Bulk import and export using the DB''s tool (for example, bulk import with LOAD DATA INFILE for MySQL or BCP for SQL Server). ActiveWarehouse ETL currently implements the import functionality for MySQL only. 3.) Views support. I''ve redefined tables, created a new method for views and a new method to get the SQL query used for the view, and added a supports_views? method. This is implemented in the Rails SQL Views plugin. One other thing I would like to see is for the following methods to be moved out of AR::Base if possible and moved into the adapter layer or into their own module so they can be reused easier: sanitize_sql replace_bind_variables replace_named_bind_variables quote_bound_value raise_if_bind_arity_mismatch V/r Anthony Eden -- Cell: 808 782-5046 Current Location: Melbourne, FL --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 2/24/07, Anthony Eden <anthonyeden@gmail.com> 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. > > 1.) Truncate. Currently implemented in ActiveWarehouse ETL for MySQL.truncate as in ''truncate table foo''?> 2.) Bulk import and export using the DB''s tool (for example, bulk > import with LOAD DATA INFILE for MySQL or BCP for SQL Server). > ActiveWarehouse ETL currently implements the import functionality for > MySQL only.This stuff should definitely remain in plugins> 3.) Views support. I''ve redefined tables, created a new method for > views and a new method to get the SQL query used for the view, and > added a supports_views? method. This is implemented in the Rails SQL > Views plugin.> One other thing I would like to see is for the following methods to be > moved out of AR::Base if possible and moved into the adapter layer or > into their own module so they can be reused easier: > > sanitize_sql > replace_bind_variables > replace_named_bind_variables > quote_bound_value > raise_if_bind_arity_mismatchI think this is one of the messier areas of the current query generation code. Because we do replace_bind_variables on each of the [string, val, val] blocks we''re passed, we can''t use prepared statements. Now while this doesn''t matter for mysql or postgresql, in the big commercial databases it makes a huge difference. If we were instead to build up some in memory structure representing the query, then pass it to the adapters to convert to a SQL string, adapters which need prepared statements could utilise them. Chances are the code would improve too. -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 2/24/07, Michael Koziarski <michael@koziarski.com> wrote:> > On 2/24/07, Anthony Eden <anthonyeden@gmail.com> 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. > > > > 1.) Truncate. Currently implemented in ActiveWarehouse ETL for MySQL. > > truncate as in ''truncate table foo''?Yes.> > 2.) Bulk import and export using the DB''s tool (for example, bulk > > import with LOAD DATA INFILE for MySQL or BCP for SQL Server). > > ActiveWarehouse ETL currently implements the import functionality for > > MySQL only. > > This stuff should definitely remain in pluginsSo be it. :-) I just think that since it is something that is fairly standard (in the sense that most RDBMs that I''ve seen implement some sort of bulk facility) it would be nice if it was defined at the adapter level with a common method or set of methods to get at it. But no worries one way or another.> > 3.) Views support. I''ve redefined tables, created a new method for > > views and a new method to get the SQL query used for the view, and > > added a supports_views? method. This is implemented in the Rails SQL > > Views plugin. > > > > > One other thing I would like to see is for the following methods to be > > moved out of AR::Base if possible and moved into the adapter layer or > > into their own module so they can be reused easier: > > > > sanitize_sql > > replace_bind_variables > > replace_named_bind_variables > > quote_bound_value > > raise_if_bind_arity_mismatch > > I think this is one of the messier areas of the current query > generation code. Because we do replace_bind_variables on each of the > [string, val, val] blocks we''re passed, we can''t use prepared > statements. Now while this doesn''t matter for mysql or postgresql, > in the big commercial databases it makes a huge difference.Indeed.> If we were instead to build up some in memory structure representing > the query, then pass it to the adapters to convert to a SQL string, > adapters which need prepared statements could utilise them. Chances > are the code would improve too.Agreed. Personally I''d like to see ezwhere integrated and used as the interface over this in-memory query structure. V/r Anthony -- Cell: 808 782-5046 Current Location: Melbourne, FL --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> 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 :) -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Feb 24, 7:44 pm, "Michael Koziarski" <mich...@koziarski.com> 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 ). I''d like to see query components be handled LIFO style. This will keep the adapters registered on AbstractAdapter as the last resort, so a plugin or adapter specific behavior can override the generic support should it need to, without having to change AbstractAdapter code. I''d like to see a nice way to handle prefix and suffix modifiers when using a Hash in #find related queries. This will allow you to support easier to read queries using suffixes like, "fieldname_matches" or "fieldname_contains" or "fieldname_is_not", etc. What I''d like to see I''ve added to ActiveRecord::Extensions, but it''d be nice to have ActiveRecord support these things because I believe it will make it easier for contributors to add functionality for different databases since they won''t have to understand the internals of ActiveRecord, instead they can focus on their query component, and simply add one line of code to register it. My last request is that it is easier and more inviting for people to contribute. 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 2/25/07, zdennis <zach.dennis@gmail.com> wrote:> On Feb 24, 7:44 pm, "Michael Koziarski" <mich...@koziarski.com> 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. I''d like to see a nice way to handle prefix and suffix modifiers when> using a Hash in #find related queries. This will allow you to support > easier to read queries using suffixes like, "fieldname_matches" or > "fieldname_contains" or "fieldname_is_not", etc.Agreed. There is similar support for attribute methods using attribute_method_suffix. What I''d like to see I''ve added to ActiveRecord::Extensions, but it''d> be nice to have ActiveRecord support these things because I believe it > will make it easier for contributors to add functionality for > different databases since they won''t have to understand the internals > of ActiveRecord, instead they can focus on their query component, and > simply add one line of code to register it.Again, the ''registering components'' bit seems very strange to me. It''s not solving any problems IMO. 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? jeremy --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Ok, my patches are quite limited to get the InterBase driver going.
At the moment, the InterBase driver is a patch on ActiveRecord, I clearly
(after my discussions with you) have to turn this into a plugin. I do need
one thing:
InterBase uses UPPER for case insignifcance, it doesn''t have LOWER
built in
(not ANSI-SQL compliant) so I added in a property to abstract_adapter.rb:
+
+ # Some databases use UPPER to determine case insignificance rather
than LOWER
+ # This is particularly used in Validations. This addition leaves
behaviour at what it is now.
+ def case_insignificant_uses_lower
+ true
+ end
and in validations.rb
if value.nil? || (configuration[:case_sensitive] ||
!columns_hash[attr_name.to_s].text?)
condition_sql = "#{record.class.table_name}.#{attr_name}
#{attribute_condition(value)}"
condition_params = [value]
+ elsif !record.connection.case_insignificant_uses_lower
+ condition_sql =
"UPPER(#{record.class.table_name}.#{attr_name})
#{attribute_condition(value)}"
+ condition_params = [value.upcase]
else
condition_sql =
"LOWER(#{record.class.table_name}.#{attr_name})
#{attribute_condition(value)}"
condition_params = [value.downcase]
All my other changes were fixing Tests and "= NULL" and "IS
NULL".
Richard
On 2/25/07, Michael Koziarski <michael@koziarski.com>
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 :)
>
>
--~--~---------~--~----~------------~-------~--~----~
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-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---
has_many_polymorphs ( http://blog.evanweaver.com/pages/has_many_polymorphs ) use a custom AR association/reflection type now. I am pushing towards eliminating the "can''t eager load polymorphic associations error" for all polymorphic relationships. Also, re. Zach:> - adding query support for regular expressions, and having better > - adding block based foreign key enable/disable supportHave you made these patches publicly available?> - adding fulltext index searching support for MySQLI have a Sphinx model for use with the SphinxSE MySQL special engine type. It doesn''t patch AR though. Evan Weaver --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 2/25/07, Michael Koziarski <michael@koziarski.com> wrote:> > I think this is one of the messier areas of the current query > generation code. Because we do replace_bind_variables on each of the > [string, val, val] blocks we''re passed, we can''t use prepared > statements. Now while this doesn''t matter for mysql or postgresql, > in the big commercial databases it makes a huge difference. >Hey buddy, please do elaborate on that last sentence. Postgres doesn''t benefit from prepared statements? What kind of performance improvements have you (not) been seeing? What kind of data/queries? As you mention mysql and postgres in the same breath I''m thinking this is just FUD, but if there''s really something here I''m eager to know. Thanks, Isak --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 2/26/07, Isak Hansen <isak.hansen@gmail.com> wrote:> > > Postgres doesn''t benefit from prepared statements? What kind of > performance improvements have you (not) been seeing? What kind of > data/queries?Koz has just been stating (I guess) that MySQL and Postgres don''t suffer as much when you don''t use prepared statements. Naturally, repeated queries (like AR model inserts, updates) would benefit from prepared statements even in those database, but in DB2 and Oracle the difference is much more stressed. --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> As you mention mysql and postgres in the same breath I''m thinking this > is just FUD, but if there''s really something here I''m eager to know.Foo.find(:all, :conditions=>["bar = ?", bar) Without changing our API there''s no way we could specify the data type of a parameter to a prepared statement. As the postgres optimizer creates the execution plan when the prepared statement is created, it wouldn''t be able to decide (sanely) which indexes to use, and query execution performance suffers. -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Feb 25, 8:07 pm, "Evan" <ewea...@gmail.com> wrote:> has_many_polymorphs (http://blog.evanweaver.com/pages/has_many_polymorphs > ) use a custom AR association/reflection type now. I am pushing > towards eliminating the "can''t eager load polymorphic associations > error" for all polymorphic relationships. > > Also, re. Zach: > > > - adding query support for regular expressions, and having better > > - adding block based foreign key enable/disable support > > Have you made these patches publicly available?rubyforge site:http://rubyforge.org/projects/arext/ official project blog: http://continuousthinking.com/tags/arext download link: http://rubyforge.org/frs/?group_id=2113 RDOC: http://continuousthinking.com/tags/arext/rdoc/index.html (scroll down to the ActiveRecord::Extensions:Regexp.... classes)> > > - adding fulltext index searching support for MySQL > > I have a Sphinx model for use with the SphinxSE MySQL special engine > type. It doesn''t patch AR though.I haven''t used Sphinx. Is it alot better then MySQL''s builtin support? 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Feb 25, 5:28 pm, "Jeremy Kemper" <jer...@bitsweat.net> wrote:> On 2/25/07, zdennis <zach.den...@gmail.com> wrote: > > > On Feb 24, 7:44 pm, "Michael Koziarski" <mich...@koziarski.com> 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 2/26/07, zdennis <zach.dennis@gmail.com> wrote:> > 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.I understand where you''re coming from; however: 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.there just isn''t that much code here! It''s a handful of methods. Adding this query handler registration scheme is easily more complex than the code it''s mean to simplify. That said, I like the ideas you''re wrapping *within* these handlers. jeremy --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Thanks for the links. The Sphinx storage engine actually creates fake tables - you add some custom parameters and it calls out to the Sphinx searchd process which can be on another box entirely. So you perform a SELECT * WHERE query = ''your search query;your=custom;params=here''; and get back a rowset. Because it operates within MySQL itself you can join at the source to your actual full records. Sphinx itself is somewhat awkward to get running. Performance is stellar, though. Once I deploy my Sphinx wrappers on our high-volume site (mid next week probably), I''ll make a post on my blog, if you want to keep an eye on that. Evan Weaver http://blog.evanweaver.com On Feb 26, 5:59 pm, "zdennis" <zach.den...@gmail.com> wrote:> On Feb 25, 8:07 pm, "Evan" <ewea...@gmail.com> wrote: > > > has_many_polymorphs (http://blog.evanweaver.com/pages/has_many_polymorphs > > ) use a custom AR association/reflection type now. I am pushing > > towards eliminating the "can''t eager load polymorphic associations > > error" for all polymorphic relationships. > > > Also, re. Zach: > > > > - adding query support for regular expressions, and having better > > > - adding block based foreign key enable/disable support > > > Have you made these patches publicly available? > > rubyforge site:http://rubyforge.org/projects/arext/ > official project blog:http://continuousthinking.com/tags/arext > download link:http://rubyforge.org/frs/?group_id=2113 > RDOC:http://continuousthinking.com/tags/arext/rdoc/index.html > (scroll down to the ActiveRecord::Extensions:Regexp.... classes) > > > > > > - adding fulltext index searching support for MySQL > > > I have a Sphinx model for use with the SphinxSE MySQL special engine > > type. It doesn''t patch AR though. > > I haven''t used Sphinx. Is it alot better then MySQL''s builtin support? > > 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 2/26/07, Michael Koziarski <michael@koziarski.com> wrote:> > > Foo.find(:all, :conditions=>["bar = ?", bar) > > Without changing our API there''s no way we could specify the data type > of a parameter to a prepared statement.Foo.find(:all, :conditions => { :bar => bar }) Now we can, because AR knows about the "bar" column and its type. AR adapters could use prepared statements when applicable. Executes could fall back to plain queries when execution would suffer (like in your example). Or am I overseeing something? --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
It's certainly possible to support prepared statements for a subset of our api, and i'd expect people will provide patches and benchmarks once the adapters make it feasible. Just don't expect them to provide some magic performance boosts on all adapters. It's entirely possible that the code complexity would outweigh any performance improvements :). On 2/28/07, Mislav Marohnić <mislav.marohnic@gmail.com> wrote:> On 2/26/07, Michael Koziarski <michael@koziarski.com> wrote: > > > > > > Foo.find(:all, :conditions=>["bar = ?", bar) > > > > Without changing our API there's no way we could specify the data type > > of a parameter to a prepared statement. > > > Foo.find(:all, :conditions => { :bar => bar }) > > Now we can, because AR knows about the "bar" column and its type. AR > adapters could use prepared statements when applicable. Executes could fall > back to plain queries when execution would suffer (like in your example). > > Or am I overseeing something? > > > >-- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 2/24/07, Anthony Eden <anthonyeden@gmail.com> 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. >What do you all think of adding a new key to find''s option hash, for adapter specific extensions, optimizer hints and similar? Unrecognized keys would just be ignored. E.g.: find(:all, :conditions => query, :ext => { :prepare => false, :db2 => {:prepare => true}, :mxyzptlk => false }) Isak --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Well, I have a plugin called find_condition that I''ve had to monkeypatch AR for. With find_condition installed, any AR class that defines find_condition() as a class method will insert that condition into *any* find() on the class, whether it is direct or through an association from some other class. The direct reason for this is to allow me to implement my acts_as_invisible class, which conditionally hides rows of a table based on various conditions, generally if the current User is not in the group identified by the visible_to field. --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Mar 3, 12:18 am, "leei" <l...@ece.ubc.ca> wrote:> Well, I have a plugin called find_condition that I''ve had to > monkeypatch AR for. > > With find_condition installed, any AR class that defines > find_condition() as a class method will insert that condition into > *any* find() on the class, whether it is direct or through an > association from some other class. > > The direct reason for this is to allow me to implement my > acts_as_invisible class, which conditionally hides rows of a table > based on various conditions, generally if the current User is not in > the group identified by the visible_to field.Is this equivalent to creating role-driven views in the application, rather then enforcing them with a view at the database level? Any particular reason(s) why you did one over the other? 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
To bump this thread... http://www.continuousthinking.com/2007/3/15/refactoring-activerecord-base Since AR can change so rapidly, I am planning on working on the majority my patch over the weekend so I can propose changes before to much else changes. After the first patch is done I will submit it to those here on core, to receive some feedback, suggestions and criticism, and also to give me some time to reflect. After that I''m planning on revising the patch one or two more times before submitting for a final submission to AR itself. I''m game for remote pairing as well as I believe two heads are better then one, and that it will be most crucial to keep these changes as simple and as clean as possible. Any core dev or AR hacker interested? Zach On Mar 2, 7:58 am, "Isak Hansen" <isak.han...@gmail.com> wrote:> On 2/24/07, Anthony Eden <anthonye...@gmail.com> 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. > > What do you all think of adding a new key to find''s option hash, for > adapter specific extensions, optimizer hints and similar? Unrecognized > keys would just be ignored. > > E.g.: > find(:all, :conditions => query, :ext => { :prepare => false, :db2 => > {:prepare => true}, :mxyzptlk => false }) > > Isak--~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Sorry for the late response - missed this thread until now. In my hacking with AR, there have been two big frustrations: 1. A lot of things are done via metaprogramatically rewriting classes, as opposed to breaking things down into an object model. Example: The DSL for validations is wonderful. There have been a lot of requests to make it depend on different contexts (see http://www.martinfowler.com/bliki/ContextualValidation.html ). I tried doing this, but gave up - if you look at the validation DSL methods, they rewrite the class. It''s quite hard to decompose them or modify them. A simpler way would be to have a @validations collection in each AR class (or perhaps each instance could have their own). The DSL would add to the collection, and valid? would check them all. Then it would be easy to: * Use the DSL to make validators for different contexts * Use the DSL and non ActiveRecord objects (frequently requested, also) * Add validators programatically (for some of those hypermodern admin interfaces) 2. Handling SQL as strings, as opposed to query + params. This is the big one that all plug in authors seem to complain about. It makes it really hard to get down deep into AR (and can make porting things harder as well). Besides the plugin benefit, handling the SQL as a query + params has 2 *huge* benefits: A. We can, similar to DBI, first create the query, and then use it with new params. According to Stefan Kaes ( http://www.infoq.com/articles/Rails-Performance ) , AR spends more time feeding the db the SQL than the DB takes to run it! B. BLOBs. Passing them into the string makes everything slow and ugly. I would guess a 10x speed improvement on large BLOBs. On this point, what I''d like to see - ideally - is using something like DBI at the base level, with AR building on top of it. DBI lacks some functionality that AR has - but that can be added into DBI just as easily as AR. This would make porting AR to new databases easier, and would also allow cross polination between Rails'' users and the general Ruby community at large (who may want to access their db''s without AR). (Note: if there are other problems with DBI that I''m not aware of - we could still use something similar - the point is to have 1 layer for querying, reflecting on, and talking to the DB, and another layer for AR''s magic) On Feb 24, 8:44 pm, "Michael Koziarski" <mich...@koziarski.com> 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 :) > > -- > Cheers > > Koz--~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Mar 15, 2007, at 2:07 PM, S. Robert James wrote:> On this point, what I''d like to see - ideally - is using something > like DBI at the base level, with AR building on top of it.I presume you are referring to: http://rubyforge.org/projects/ruby-dbi/ Anyone have experience using it? -- Ernie P.> On this point, what I''d like to see - ideally - is using something > like DBI at the base level, with AR building on top of it. DBI lacks > some functionality that AR has - but that can be added into DBI just > as easily as AR. This would make porting AR to new databases easier, > and would also allow cross polination between Rails'' users and the > general Ruby community at large (who may want to access their db''s > without AR). (Note: if there are other problems with DBI that I''m not > aware of - we could still use something similar - the point is to have > 1 layer for querying, reflecting on, and talking to the DB, and > another layer for AR''s magic--~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
In my plugin for specifying custom finder SQL for eager-loading of associations ( http://rubyforge.org/projects/eagerfindersql ), I needed to work hard to avoid not completely re-implementing each associated class. I needed to pass extra options in ActiveRecord::Associations::find_with_assocations down into private subclasses: ActiveRecord::Associations::JoinDependency and JoinBase. To keep from having to redefine the initializer for each of these classes, I ended up using a thread variable to hold the mapping data structures needed to assign results from the query to different associations. Not an ideal solution, but it did solve the problem with minimal overriding of methods within these classes. Gregg Kellogg www.kellogg-assoc.com --~--~---------~--~----~------------~-------~--~----~ 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-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---