Mysql quotation wonky

Rails
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

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

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

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.