On 2/24/07, Michael Koziarski <[EMAIL PROTECTED]> wrote: > > On 2/24/07, Anthony Eden <[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. > > > > 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 plugins So 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 [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 -~----------~----~----~----~------~----~------~--~---
