Following a thread from some time ago, "a remote database issue", in which Jeremy Kemper posted his config and rakefile code that automatically dumps a "fixtures" database into yaml files (among other things), I tried to duplicate this on my machine and got the following error: rake aborted! undefined method `table_names'' for #<ActiveRecord::ConnectionAdapters::MysqlAdapter:0x2521f04> ./rakefile:198 The offending line in the Rakefile is: ActiveRecord::Base.connection.table_names.each do |table_name| And indeed, looking at MysqlAdapter, there is no such thing as "table_names". In fact, the Postgres adapter doesn''t seem to have such a method either. Has this changed since March? Is there another way to reflect on all of the table names in a MySQL database? Thanks, Duane Johnson (canadaduane) _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On May 21, 2005, at 8:28 PM, Duane Johnson wrote:> And indeed, looking at MysqlAdapter, there is no such thing as > "table_names". In fact, the Postgres adapter doesn''t seem to have > such a method either. Has this changed since March? Is there > another way to reflect on all of the table names in a MySQL database?I added table_names methods to the MySQL, SQLite, and PostgreSQL adapters to support this rake task. I''m not using fixtures at all any more (cloning a pristine fixtures db to a scratch database before tests) so I excised the code and that rake task. It''s some pretty simple SQL, if you''d like to work it up again (try ''show tables'' in MySQL.) Best, jeremy
> I added table_names methods to the MySQL, SQLite, and PostgreSQL > adapters to support this rake task. I''m not using fixtures at all > any more (cloning a pristine fixtures db to a scratch database > before tests) so I excised the code and that rake task. It''s some > pretty simple SQL, if you''d like to work it up again (try ''show > tables'' in MySQL.)Thanks, Jeremy. Now just one more thing... how can I take these generated yml files and put them back in the database? I know the test_units target somehow does this for the test database. I''d like to be able to specify the development database, to create a fresh db like you''ve done, but using yml instead of cloning the fixtures db. For anyone who''d like to do something similar, here''s what I added to my :environment task in my Rakefile to make reflecting on the table names in the db possible: desc ''Require application environment.'' task :environment do unless defined? RAILS_ROOT require File.dirname(__FILE__) + ''/config/environment'' # ---- Custom method used in yaml_fixtures target ---- # Gets all of the table names in a database and returns them as an array class ActiveRecord::ConnectionAdapters::MysqlAdapter def table_names(name = nil) sql = "SHOW TABLES" tables = [] execute(sql, name).each { |field| tables << field[0] } tables end end # ---- End of custom method ---- end end _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On May 21, 2005, at 10:45 PM, Duane Johnson wrote:>> I added table_names methods to the MySQL, SQLite, and PostgreSQL >> adapters to support this rake task. I''m not using fixtures at all >> any more (cloning a pristine fixtures db to a scratch database >> before tests) so I excised the code and that rake task. It''s some >> pretty simple SQL, if you''d like to work it up again (try ''show >> tables'' in MySQL.) > > Thanks, Jeremy. Now just one more thing... how can I take these > generated yml files and put them back in the database? I know the > test_units target somehow does this for the test database. I''d > like to be able to specify the development database, to create a > fresh db like you''ve done, but using yml instead of cloning the > fixtures db.Something like class ActiveRecord::ConnectionAdapters::AbstractAdapter def create_all_fixtures Fixtures.create_fixtures "#{RAILS_ROOT}/test/fixtures", table_names end end ActiveRecord::Base.establish_connection :development ActiveRecord::Base.connection.create_all_fixtures should mend your wagon. Best, jeremy
Michael Campbell
2005-May-22 16:01 UTC
Re: How might I reflect on the table names in a db?
On 5/21/05, Jeremy Kemper <jeremy-w7CzD/W5Ocjk1uMJSBkQmQ@public.gmane.org> wrote:> I added table_names methods to the MySQL, SQLite, and PostgreSQL > adapters to support this rake task. I''m not using fixtures at all > any more (cloning a pristine fixtures db to a scratch database before > tests) so I excised the code and that rake task. It''s some pretty > simple SQL, if you''d like to work it up again (try ''show tables'' in > MySQL.)Jeremy, isn''t that what the rake task for unit tests does already? Clones the dev db into test, then loads whatever fixtures you specify? What are you saving in doing this differently? (Curious, because I consider my tests pretty slow; the rake tasks reports 4 or so seconds to run, but the overhead is easily 5x that.)
On May 22, 2005, at 9:01 AM, Michael Campbell wrote:> On 5/21/05, Jeremy Kemper <jeremy-w7CzD/W5Ocjk1uMJSBkQmQ@public.gmane.org> wrote: >> I added table_names methods to the MySQL, SQLite, and PostgreSQL >> adapters to support this rake task. I''m not using fixtures at all >> any more (cloning a pristine fixtures db to a scratch database before >> tests) so I excised the code and that rake task. It''s some pretty >> simple SQL, if you''d like to work it up again (try ''show tables'' in >> MySQL.) > > Jeremy, isn''t that what the rake task for unit tests does already? > Clones the dev db into test, then loads whatever fixtures you specify?I have a separate database (not dev) with all my test fixtures preloaded. Clone the fixtures database to a scratch database for the unit tests: createdb -O app_user -T app_fixtures app_test Then set Test::Unit::TestCase.use_transactional_fixtures = true in test/test_helper.rb to wrap every test case in a transaction that''s rolled back at the end of the case, ensuring isolation. Since the test database is unchanged after each test I only have to re-clone it when the fixtures database is modified. Now all your fixtures are preloaded so you never have to specify "fixtures ..." in any of your tests. This drastically speeds up test startup and runtime which allows you to be properly OCD about running them at every opportunity.> What are you saving in doing this differently? (Curious, because I > consider my tests pretty slow; the rake tasks reports 4 or so seconds > to run, but the overhead is easily 5x that.)I never have to reload fixtures between test cases so I''m saving N test cases * M tables * (1 delete + P inserts + P selects for instantiated fixtures) = a metric ass load of queries. By using transactional fixtures I''m also avoiding the test db clone at the beginning of each test run. Check out ''rake recent'' for additional speedup: it limits tests to those for files that have changed in the last 10 minutes. Best, jeremy