Rails keeps trying to use SQLite , despite that I've configured MySQL for my project - mysql

I setup my rails project "tracks" using:
$ rails --database=mysql tracks # OK
$ cd tracks
$ vim config/database.yml # correct using mysql adapter, added password spec
$ rake db:create RAILS_ENV='development' # OK
$ rake db:migrate # OK
$ ruby script/generate scaffold user name:string password:string email:string url:string # OK
$ rake db:migrate # OK, creates table
$ ruby script/server # OK, starts WEBrick
I open up the thing in a web browser:
http://localhost:3000 # correctly shows the rails welcome splash
I navigate to
http://localhost:3000/users/new
and get a huge slew of errors:
ActiveRecord::StatementInvalid in UsersController#index
SQLite3::SQLException: no such table: users: SELECT * FROM "users"
RAILS_ROOT: /home/drew/tracks/trunk/tracks
Application Trace | Framework Trace | Full Trace
vendor/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:188:in `log'
vendor/rails/activerecord/lib/active_record/connection_adapters/sqlite_adapter.rb:132:in `execute'
vendor/rails/activerecord/lib/active_record/connection_adapters/sqlite_adapter.rb:372:in `catch_schema_changes'
vendor/rails/activerecord/lib/active_record/connection_adapters/sqlite_adapter.rb:132:in `execute'
vendor/rails/activerecord/lib/active_record/connection_adapters/sqlite_adapter.rb:275:in `select'
vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:7:in `select_all_without_query_cache'
vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:60:in `select_all'
vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:81:in `cache_sql'
vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:60:in `select_all'
vendor/rails/activerecord/lib/active_record/base.rb:635:in `find_by_sql'
vendor/rails/activerecord/lib/active_record/base.rb:1490:in `find_every'
vendor/rails/activerecord/lib/active_record/base.rb:589:in `find'
app/controllers/users_controller.rb:5:in `index'
wtf? Why is ruby still trying to use SQLite? database.yml has zero mention of SQLite.
Thanks

Couldn't figure it out. I ended up reinstalling the OS on the VM and trying again and it worked.
FYI: Do not install rubygems from a package manager like apt-get. Compile it from source or it will all end in tears.

Had this problem, I found all of the files using "find . | xargs grep 'sqlite3' -sl then replaced all of the yml and rb files it found then restarted the server.
Unfortunately, I don't know which (if any, as it may have been the server restart) solved the issue, but now I'm on and up.
Hope that helps someone, however 'hacky'.

Quick Fix that i've used is...
When i start a project a specify the -d for database
rails -d mysql ProjectName
Which builds the database.yml file for mysql
hope this helps.

As odd as it might sound, try clearing your browser's cookies. I had a similar problem moving from sqlite to postgresql and vice versa. It turns out the stored cookie or session was somehow making the server get stuck in using the old database. If this works then you'll want to take steps on your server to invalidate any existing cookies in your users' browsers.

Don't mean to necro, but if someone runs onto this problem, edit your config/database.yml file, and remove the line that says << default from the production section. What this is doing is loading the default environment first, so Passenger loads it instead of whatever else you've configured.

Related

Mysql2::Error: # MySQL client is not connected — Rails 6.0.2.2 with rspec; Ruby 2.6.4 mac os Catalina + Mojave

I'm getting this extremely strange intermittent problem with MySQL on Rails 6.0.2.2,
RSpec 4.0.0.rc1,
Ruby 2.6.4
on a two separate Macs, one is running macOS Mojave and the other is running MacOS Catalina
Interestingly, the mac running Catalina appears to do it less often, although it still does this. the failure is intermittent, seems to happen immediately after another failure in the suite, but then often continues to show up (across about half of the test suite) on subsequent runs, even if I've fixed the originally failing spec.
1) Template
Failure/Error: _query(sql, #query_options.merge(options))
ActiveRecord::StatementInvalid:
Mysql2::Error: MySQL client is not connected
# /Users/jason/.rvm/gems/ruby-2.6.4/gems/mysql2-0.5.3/lib/mysql2/client.rb:131:in `_query'
# /Users/jason/.rvm/gems/ruby-2.6.4/gems/mysql2-0.5.3/lib/mysql2/client.rb:131:in `block in query'
# /Users/jason/.rvm/gems/ruby-2.6.4/gems/mysql2-0.5.3/lib/mysql2/client.rb:130:in `handle_interrupt'
# /Users/jason/.rvm/gems/ruby-2.6.4/gems/mysql2-0.5.3/lib/mysql2/client.rb:130:in `query'
# /Users/jason/.rvm/gems/ruby-2.6.4/gems/rspec-wait-0.0.9/lib/rspec/wait.rb:46:in `block (2 levels) in <top (required)>'
# ------------------
# --- Caused by: ---
# Mysql2::Error:
# MySQL client is not connected
# /Users/jason/.rvm/gems/ruby-2.6.4/gems/mysql2-0.5.3/lib/mysql2/client.rb:131:in `_query'
I began having this problem when I set up my personal laptop (Mac OS Catalina) to do work from home. In the process, I updated our environment from Ruby 2.4.7 to 2.6.3 and gems system from 3.0.6 to 3.1.2. And, no doubt, incremental updates to our bundled gems also happened. I have not been able to identify which change resulted in the new, seemingly random and intermittent failures.
Google led me here first, and second to this discussion on a minitest issue:
https://github.com/seattlerb/minitest/issues/744
Then, looking closer at my tests, I noticed that the first test to fail always triggered an async method.
I added this to my config/environments/test.rb file:
config.active_job.queue_adapter = :inline
And all tests are passing again.
I don't know if this constitutes a fix or a work around. I'm not sure if asynchronous processes were working before or if they were previously being handled inline and a default behavior changed. The tests we currently have aren't specifically validating asynchronicity. So, for the moment, this solved my problem.
In my case I had issues while running tests for ActiveJob background jobs, and
adding config.active_job.queue_adapter = :test to config/environments/test.rb worked for me.

Laravel 5.1 - `php artisan migrate` is giving 'PDOException'

I know this is a duplicate question however whatever I tried, unfortunately no luck. (To add, I am using MAMP)
I believe I successfully setup the database connection because, using the registration form (Auth/register), after submitting the form, I was getting the error PDO Exception: Driver not found before, but after changing to my MAMP to PHP 5.5.17 from the default(PHP 5.6.1), I started getting error: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'laravel.users' doesn't exist, which I believe shows that the database connection is working and it's just the 'users table' is not created.
Here starts my problem. When I try to use php artisan migrate or migrate:{anything} in the terminal, it's throwing the error:
[PDOException]
could not find driver
But what I want to do is to use php artisan migrate to be able to create tables and migrate them.
Things I have tried:
I added <?php echo phpinfo(); ?> to if pdo files are successfully installed.
I get the result:
so I think it seems okay.
People were talking about opening /MAMP/bin/php/php5.6.1/conf/php.ini and adding extension=pdo_mysql.so in the code, but I have mine already placed there.
When I try php -i | grep PDO in the project root (/MAMP/htdocs/proj), I got:
PDO
PDO support => enabled
PDO drivers => sqlite
PDO Driver for SQLite 3.x => enabled
php -i | grep Conf and `php --ini also outputs:
Configuration File (php.ini) Path: /Applications/MAMP/bin/php/php5.6.1/conf
Loaded Configuration File: /Applications/MAMP/bin/php/php5.6.1/conf/php.ini but php artisan migrate still throwing the same error
SOLUTION:
I chose MAMP to use version 5.5.17 instead of 5.6.1 in the browser (from MAMP Preferences), however this time terminal was running the 5.6.1. What I did was first checking which PHP command and then, running the nano ~/.bash_profile command; and editing the version document. Now everything is up and running :)
What you see in the browser is that you have PDO enabled for PHP running through apache. But this does not mean you have it enabled for PHP running through CLI (in fact they are using two separate ini files). To confirm that you can try:
php -i | grep PDO
And you will see it is missing or not enabled. So what you need to do is to find which php.ini is using the PHP running through CLI and add the PDO module there:
php -i | grep Conf
It will output something like:
Configuration File (php.ini) Path => /etc/php5/cli
Loaded Configuration File => /etc/php5/cli/php.ini

NameError: cannot load Java class com.mysql.jdbc.Driver

I'm using JRuby 1.7.2, along with DataMapper, and I'm getting an error I can't find an answer to.
I'm just testing out DataMapper along with MySQL 5.5 to see if it will run fine when I build around it. Here's the file I'm testing:
require "data_mapper"
require "keys"
DataMapper.setup(:default, "mysql://#{$user}:#{$pass}#localhost/test_db")
And when I run this, I get the error:
NameError: cannot load Java class com.mysql.jdbc.Driver
And it points to the DataMapper.setup line.
My Gemfile should be alright:
source :rubygems
gem "sinatra"
gem "trinidad"
gem "data_mapper"
# do a `sudo apt-get install libmysqlclient-dev` first
gem "dm-mysql-adapter"
gem "jdbc-mysql"
Is there anything I'm missing? I have MySQL set up with a user/pass locally already.
This is a common error when running JDBC clients for MySQL. You need to make sure you have mysql-connector-java-bin.jar on the classpath. You can download it from here.
I'm using Rails 3.2.9 and to solve the problem I added this to my application.rb
if defined? JRUBY_VERSION
require 'jdbc/mysql'
Jdbc::MySQL.load_driver
end
actually, the correct answer is to work-around an incompatibility between 5.1.13 and 5.1.22 !
jdbc-mysql gem already contains the mysql-connector.jar it just ain't auto-loading anymore :
https://github.com/jruby/activerecord-jdbc-adapter/tree/master/jdbc-mysql (read the README)
you can also force the driver to auto-load using a Java system property e.g. from a cmd line :
jruby -J-Darjdbc.mysql.autoload=true -S rake ...
I had the same error when trying to use a mysql database from jruby/rails4. In my case this line was missing from ./Gemfile:
gem 'jdbc-mysql'

Ruby on Rails MySQL #08S01Bad handshake - downgrade MySQL?

We recently upgraded from MySQL 5.1.41 to 5.1.61 on our Ubuntu 10.04LTS server. We have an ancient RoR web app that's now giving a bad handshake error:
Mysql::Error in MainController#index
#08S01Bad handshake
/usr/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/vendor/mysql.rb:523:in `read'
/usr/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/vendor/mysql.rb:153:in `real_connect'
/usr/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/mysql_adapter.rb:389:in `connect'
/usr/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/mysql_adapter.rb:152:in `initialize'
/usr/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/mysql_adapter.rb:82:in `new'
/usr/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/mysql_adapter.rb:82:in `mysql_connection'
/usr/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/abstract/connection_specification.rb:262:in `send'
/usr/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/abstract/connection_specification.rb:262:in `connection_without_query_cache='
/usr/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/query_cache.rb:54:in `connection='
/usr/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/abstract/connection_specification.rb:230:in `retrieve_connection'
/usr/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/abstract/connection_specification.rb:78:in `connection'
/usr/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/base.rb:763:in `columns'
/usr/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/base.rb:2060:in `attributes_from_column_definition_without_lock'
/usr/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/locking/optimistic.rb:45:in `attributes_from_column_definition'
/usr/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/base.rb:1502:in `initialize_without_callbacks'
/usr/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/callbacks.rb:225:in `initialize'
#{RAILS_ROOT}/app/controllers/application.rb:48:in `new'
#{RAILS_ROOT}/app/controllers/application.rb:48:in `log_info'
/usr/local/bin/mongrel_rails:19:in `load'
/usr/local/bin/mongrel_rails:19
I googled around and stumbled onto http://bugs.ruby-lang.org/issues/5017 which tells me it's a Ruby MySQL extension bug. We aren't using the MySQL gem. Our web app is incredibly old and fragile (Ruby v1.8.7, Rails v1.2.3, Mongrel 1.1.5). We're in the process of replacing it with a Django rewrite, so we just need to get this functional for the next few weeks until we will replace it with the new site.
How can we get past this error? I'm thinking that downgrading to MySQL 5.1.41 is the best way to handle this, and then when we begin using the new site in a few weeks, we can re-upgrade to 5.1.61. However, I'm having an issue downgrading mysql. This is the command I'm using:
sudo aptitude install mysql-server-5.1=5.1.41-3ubuntu12.10
However, this tells me Unable to find a version "5.1.41-3ubuntu12.10" for the package "mysql-server-5.1". I've tried sudo aptitude install mysql-server-5.1=5.1.41 also, but that didn't work either. How can I have aptitude install the correct version of MySQL?
Instead of downgrade MySQL gem, it's possible to fix the database name parameter to fix the "bad handshake" problem.
I found this: https://github.com/rubygems/rubygems/issues/423 It's working good.
Instead of doing a hack in real_connect it's possible to add the "\0" in config/database.yml
production:
database: "itsalive_production\0"
adapter: mysql
host: localhost
encoding: UTF8
...
EDIT
If you use the solution with \0 at the end of the database name. You probably will find find out this and solve it yourself, but I mention it anyway:
(at least in my version of Rails)
Using the database string with \0 at the end gives problem when doing rake test. It starts with deleting the test database before copying the development database definitions, and then using a SQL command string that includes the test database name. This will cause an error because of the \0 in the middle of the string.
In my case I'm using a local development database that doesn't give any problem so I don't need to have \0 in that name.
Here is a alternative hack to solve that (original code in mysql_adapter.rb):
module ActiveRecord
module ConnectionAdapters
class MysqlAdapter
alias_method :old_execute, :execute
def execute(sql, name = nil) #:nodoc:
# This is needed because database names can end with "\0" to fix
# the issue with "handshake" when mysql server is newer than the gem
# requires. E.g. called when loading the new test db when doing "rake test".
sql = sql.delete("\0")
old_execute(sql, name)
end
end
end
end
I fixed it! Downgrading MySQL did the trick. We'll re-upgrade to 5.1.61 once the Django site goes live. Here's the command to downgrade MySQL:
sudo aptitude install mysql-server-5.1=5.1.41-3ubuntu12 mysql-client-5.1=5.1.41-3ubuntu12 mysql-server-core-5.1=5.1.41-3ubuntu12
I used apt-cache to get the exact version.
I also had the same issue. Please add:
config.gem 'mysql', :version => '2.7'
Then run rake gems:install.

Multiple MySQL queries with Ruby

I'm having troubles with MySQL queries in Ruby. I use 'mysql' gem.
Configuration is stored in a separate yml file and loaded into #conf variable.
This is my code:
# connect to the database
Mysql::new(#conf['sql_host'], #conf['sql_user'], #conf['sql_password'], #conf['sql_base'])
# it's ok when we're doing this
my.query("SELECT * FROM `my_table`") do |e|
# code
end
# Maybe, I've missed something here...
# really this query will insert value into other table, used SELECT just for testing
# this throws exception: 'query: not connected'
my.query("SELECT * FROM `my_table_2`")
Windows XP
ruby 1.8.6 (2008-08-11 patchlevel 287) [i386-mswin32]
mysql (2.8.1, 2.7.3)
MySQL client version: 5.0.51a
Second query throws 'query: not connected'.
First of all, your program looks ok. I am 100% sure you have libmysql.dll version problem.
I can reproduce this with libmysql.dll provided from Mysql installer.
Download this file and replace in c:\ruby\bin\
http://instantrails.rubyforge.org/svn/trunk/InstantRails-win/InstantRails/mysql/bin/libmySQL.dll
and re-run your program without any change.
Related issue and credit to here
I have run into immeasurable problems when attempting to use Ruby's mysql gem on any version of Windows. From what I can tell, it simply doesn't work unless you can figure out how to compile it yourself (which is a royal pain in the ass).
Have you considered using ActiveRecord as your ORM (object relational mapping) layer and doing development with SQLite or some other database on Windows and then running the production environment on Linux with MySQL? This is the solution that I took a while back and it worked out quite well.