Mysql quotation wonky

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”

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?

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)?

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

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

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.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs