mysql quotation wonky

rubyonrails-talk
1

Why would, in an upgrade from 3.0.1 to 3.0.3, a rake db:migrate run this:

SELECT "schema_migrations"."version" FROM "schema_migrations"

vs this ?

SELECT `schema_migrations`.`version` FROM `schema_migrations`

__ rake db:migrate output __ rake aborted! Mysql::Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '."version" FROM "schema_migrations"' at line 1: SELECT "schema_migrations"."version" FROM "schema_migrations"

2

I have this issue in Rails 3.0.4 as well

Mysql::Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '."version" FROM "schema_migrations"' at line 1: SELECT "schema_migrations"."version" FROM "schema_migrations"

Anyone?

3

Mine are running ok in 3.0.3 (and I will try 3.0.4 tomorrow). What environment are you running on (os, ruby, gems, etc)?

4

this is happening in production only it would seem. Running 1.9.2 with an isolated gem env via rvm

Fedora release 8 (Werewolf)

Gems included by the bundle:   * ZenTest (4.4.0)   * abstract (1.0.0)   * actionmailer (3.0.4)   * actionpack (3.0.4)   * activemerchant (1.5.1)   * activemodel (3.0.4)   * activerecord (3.0.4)   * activeresource (3.0.4)   * activesupport (3.0.4)   * ar_mailer_rails3 (2.1.10)   * arel (2.0.8)   * authlogic (2.1.6)   * awesome_print (0.3.0)   * aws (2.3.20)   * aws-s3 (0.6.2)   * bind (0.2.8)   * bitly (0.5.3)   * builder (2.1.2)   * bundler (1.0.10)   * commander (4.0.3)   * configuration (1.1.0)   * countries (0.3.0)   * crack (0.1.8)   * currencies (0.2.1)   * daemons (1.1.0)   * delayed_job (2.1.0.pre2)   * diff-lcs (1.1.2)   * erubis (2.6.6)   * factory_girl (1.3.2)   * factory_girl_rails (1.0)   * faker (0.3.1)   * ffi (0.6.3)   * fuubar (0.0.2)   * haml (3.0.18)   * haml-rails (0.2)   * highline (1.6.1)   * hoptoad_notifier (2.4.2)   * http_connection (1.3.0)   * httparty (0.6.1)   * i18n (0.5.0)   * infinity (0.0.8)   * json_pure (1.4.6)   * jspec (4.3.3)   * launchy (0.3.7)   * mail (2.2.15)   * mime-types (1.16)   * mocha (0.9.11)   * mustache (0.11.2)   * mysql (2.8.1)   * newrelic_rpm (2.13.4)   * nokogiri (1.4.3.1)   * polyglot (0.3.1)   * rack (1.2.1)   * rack-mount (0.6.13)   * rack-test (0.5.7)   * rails (3.0.4)   * rails3-generators (0.13.0)   * railties (3.0.4)   * rake (0.8.7)   * recurly (0.1.4)   * rspec (2.0.1)   * rspec-core (2.0.1)   * rspec-expectations (2.0.1)   * rspec-instafail (0.1.4)   * rspec-mocks (2.0.1)   * rspec-rails (2.0.1)   * rstats (0.0.4)   * ruby-progressbar (0.0.9)   * sentient_user (0.3.0)   * simplecov (0.3.5)   * simplecov-html (0.3.8)   * sinatra (1.0)   * snogmetrics (0.1.6)   * sqlite3 (0.1.1)   * thor (0.14.6)   * treetop (1.4.9)   * tzinfo (0.3.24)   * unicorn (1.1.2)   * uuidtools (2.1.1)   * webrat (0.7.1)   * will_paginate (3.0.pre2)

then I run a rake job:

  namespace :test do     desc 'reset test db'     task :reset => :environment do       rails_env = Rails.env       Rails.env = 'test'       if ActiveRecord::Migrator.new(:up, 'db/ migrate').pending_migrations.size > 0 or ENV['FORCE']         puts "Resetting test database"         Rake::Task["db:migrate:reset"].invoke       end       Rails.env = rails_env     end   end

and it's this rake job which fails.

running just RACK_ENV=test db:migrate:reset on it's own is successful however.

so it would seem it's just this task on production which fails.

5

So I solved it by doing a RACK_ENV=test before running my task. I suspect a bug since this probably shouldn't have been required and luckily all my related tasks here were to do with test, but they may not have been.

Anyway, FYI

6

So I solved it by doing a RACK_ENV=test before running my task. I suspect a bug since this probably shouldn't have been required and luckily all my related tasks here were to do with test, but they may not have been.

Anyway, FYI