20210108のMySQLに関する記事は6件です。

herokuでデプロイをしたアプリのDBをsequel proで確認する方法

はじめに

本番環境下(今回はherokuでデプロイ)のDBの内容の確認方法を習得したので、忘れる前にメモとして残します。

Sequel ProでDB内を確認する方法

1.ターミナルにて、下記を実行
 ※()内は確認したいアプリ名を記述

heroku config --app (application_name)

2.下記の内容が出力されるので確認

CLEARDB_DATABASE_URL: mysql://(ユーザー名):(パスワード)@(ホスト)/(データベース名)?reconnect=true

3.Sequel Proを開く

4.標準を選択

5.2をSequel Proの項目に当てはめる(下記参照※パスワードも2で確認したパスワードを記述)
 ※名前はherokuなど自由な名前でOK。ポートも記載なしで確認できる。


6.接続をクリック

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【Ruby】カラムの名前間違えた&制約間違えた〜助けてmigrate〜

解決したいこと

アプリケーションを作り始めて2日目。
DB設計を終えてテーブルを作り、モデルを作り、ふと気付く。

「あれ?スペル違ってるじゃないの・・・」
「あれ?null制約かかっててコンソールからデータ追加できないじゃないの・・・」

さてこれはどうしたものかと色々調べた結果、名前だけ変えられる素晴らしいコマンドがあるとのこと。
ありがたやありがたや・・・。

該当するソースコード

class CreateParties < ActiveRecord::Migration[6.0]
  def change
    create_table :parties do |t|
      t.string  :name,          null: false
      t.text    :iintroduction, null: false    #⬅️①なぜかiが多いスペルミス
      t.integer :season_id,     null: false
      t.integer :country_id,    null: false
      t.integer :genre_id,      null: false
      t.text    :picture,       null: false    #⬅️②これも修正したい
      t.timestamps
    end
  end
end

まずは①からターミナルで実行。

% rails generate migration rename_iintroduction_column_to_parties
                                 ⬆️変えたいカラム名          ⬆️モデル名

結果がこちら。
新しくrename用のマイグレーションファイルを作ってくれます。

Running via Spring preloader in process 9848
      invoke  active_record
      create    db/migrate/20210108122152_rename_iintroduction_column_to_parties.rb

次に作成してくれたファイルに記述していきます。

class RenameIintroductionColumnToParties < ActiveRecord::Migration[6.0]

  def change
    rename_column :parties, :iintroduction, :introduction
  end             ⬆️モデル名  ⬆️変えたいカラム名  ⬆️修正後のカラム名
end

記述できたらマイグレーション。

% rails db:migrate

直った!
次は②のnull:false制約をつけてしまったものを外したいという作業。
なぜかというとレビューサイトを作っているのですが、レビューしたいデータは管理者のみが作成できるようにしたいため、ひとまずデータの投稿をコンソールから行いたかったからです。
そこで画像データをコンソールから入力しようとしたところnull:false制約がついているためコンソールからデータ入力ができずに困っておりました。
一度この制約を外してとにかく画面上に一つでもデータが表示されるようにしたいというのもあったため、取り急ぎ外すことに。
こちらも同じようなコマンドで対応可能でした。

 % bin/rails g migration ChangeColumnToAllowNull

同じくマイグレーションファイルが作成されるのでそちらに記述。

class ChangeColumnToAllowNull < ActiveRecord::Migration[6.0]

  def up
    change_column_null :parties, :picture, null: true   #「up」でnull: trueに変更しますよ、という意味
  end

  def down
    change_column_null :parties, :picture, null: false  #「down」でnull: false制約つきのものから⬆️⬆️⬆️
  end

end

記述できたらマイグレーション。

% rails db:migrate

これで制約を外すことができたのでデータを追加することができました。
そして今、わたしの目の前にはいざ画像を追加しようと思ったら容量が大きすぎて追加できないというエラーが発生しております。
さあ次の戦場へ向かおう。

参考にさせて頂いた記事

https://qiita.com/libertyu/items/93acd8733e34b1d0a63c
https://qiita.com/mom0tomo/items/31466a80ca38db4ebf8c

ありがとうございました。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Ruby on Rails 日本語でフォーム投稿した際にIncorrect string valueエラー解決方法

はじめに

環境

  • Docker
  • ruby 2.3.7
  • Rails 5.2.4.4
  • MySQL 5.7.32

エラー内容

新規投稿フォームに日本語を入力し、送信するとIncorrect string valueエラーが発生。
スクリーンショット 2021-01-04 21.28.20.png

原因

Incorrect string valueのエラー文から、フォームに入力した文字列が原因と推測。
試しに英語を入力して送信すると問題なく投稿できました。

ということは、DBが日本語に対応していない?

MySQLに接続し、使用中のデータベースの設定を確認。

mysql> show variables like '%char%';
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | latin1                     |
| character_set_connection | latin1                     |
| character_set_database   | latin1                     |
| character_set_filesystem | binary                     |
| character_set_results    | latin1                     |
| character_set_server     | latin1                     |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.00 sec)

DBの文字コードの設定がutf8ではなく、latin1になっていました。
latin1は、西ヨーロッパ言語で日本語対応していないらしいです。

Docker環境構築時にdatabase.ymlファイルの文字コードの設定が抜けていたのが原因でした。

database.yml
default: &default
  adapter: mysql2
  # ここに「charset: utf8」が抜けてたのが原因
  encoding: utf8
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
  username: root
  password: hideki1104
  host: db

解決方法

etc/mysql/my.cnfのファイルに

[mysqld]
character-set-server=utf8mb4
collation-server=utf8mb4_bin
skip-character-set-client-handshake
[mysqldump]
default-character-set=utf8mb4
[mysql]
default-character-set=utf8mb4

を記述すると文字コードが変更できます。

viエディタを使用して記述を追加しようとしたが、viコマンドが設定されておらず使えない

# vi my.cnf
/bin/sh: 5: vi: not found

apt_getを使用すればvimをインストールできるらしい。

# apt-get -v
apt 1.8.2.2 (amd64)

下記のコマンドで一旦アップデートを行い

# apt-get update

vimをインストールします。

# apt-get install vim

これでvimを使用できるようになりました。

etc/mysql/my.cnfに先ほどの

[mysqld]
character-set-server=utf8mb4
collation-server=utf8mb4_bin
skip-character-set-client-handshake
[mysqldump]
default-character-set=utf8mb4
[mysql]
default-character-set=utf8mb4

を記述することで文字コードを変更できました。

この状態ではすでに作成しているすでにDB、テーブル、カラムの文字カードは変更されていません。

MySQLの中で以下のコマンドを打ち込みました
DBの文字コード設定

ALTER DATABASE DB名 CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

テーブルの文字コード設定

ALTER TABLE テーブル名 CONVERT TO character SET utf8mb4 COLLATE utf8mb4_unicode_ci;

カラムの文字コード設定

ALTER TABLE テーブル名 CHANGE column_name カラム名 VARCHAR(10) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

これで投稿フォームで日本語を送信することができるようになりました。

参考記事

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

macでmysqlが動かなくなった時の解決策 (Railsプロジェクト動かす編)

久しぶりにローカルのmysql使ったら動かなくなった

railsプロジェクトで久しぶりにlocalのmysql使ったらmysqlが動かなくなっていました。その解決した方法を以下に記述します。

とりあえず今あるmysqlを全部消す

データ消えるけど、seedデータで入れ直しましょう。結果的に早いです。古いmysqlが悪さしている場合、解決にかなり時間を取られてしまうのでdockerでmysqlを起動させて接続するようなことをしないのであれば脳死でmysqlを消しましょう。

  • コミュニティエディションのmysqlを削除する方法
rm -rf ~/Library/PreferencePanes/My*
sudo rm /usr/local/mysql
sudo rm -rf /usr/local/mysql*
sudo rm -rf /Library/StartupItems/MySQLCOM
sudo rm -rf /Library/PreferencePanes/My*
sudo rm -rf /Library/Receipts/mysql*
sudo rm -rf /Library/Receipts/MySQL*
sudo rm -rf /private/var/db/receipts/*mysql*
sudo rm /Library/LaunchDaemons/com.oracle.oss.mysql.mysqld.plist
  • brewで入れたmysqlを削除する方法
$ brew uninstall mysql
sudo rm -rf /usr/local/Cellar/mysql*
sudo rm -rf /usr/local/bin/mysql*
sudo rm -rf /usr/local/var/mysql*
sudo rm -rf /usr/local/etc/my.cnf
sudo rm -rf /usr/local/share/mysql*
sudo rm -rf /usr/local/opt/mysql*
sudo rm -rf /etc/my.cnf

上2つとも流しておけばmysqlは全部消えるはず。

brewでmysqlをinstall

今回はbrewを使ってmysqlをinstallします。現状、brew install mysqlをすると8系列のmysqlがinstallされてしまうので、無難に5.7をinstallします。

brew install mysql@5.7

pathを通すために以下の1行を自分が使っているシェルの設定ファイルに記載してください。 ( bashなら ~/.bash_profile )

export PATH="/usr/local/opt/mysql@5.7/bin:$PATH"

※もし昔に設定していたmysqlのPATHがあったら削除しましょう。

mysql.server start
Starting MySQL
 SUCCESS!

となればmysqlのinstallまで成功です。

過去に起動したRailsプロジェクトを動かす

以下はrailsのプロジェクトを動かすときのはまりポイント置いておきます。

過去にbundle installを実行したプロジェクトだと、その時入れてあったmysqlのversionに合わせてgemがinstallされていると思うので、rails db:createを実行すると以下のようなエラーが出てmysql周りが怒られているよ!というエラーが表示されると思います。

> rails db:create
rails aborted!
LoadError: dlopen

ですので以下のコマンドでgemをuninstallします。

bundle exec gem uninstall mysql2

して

bundle install 

を実行してmysql2のgemを入れ直しましょう。
ここでエラーが出る人は

bundle config --local build.mysql2 "--with-ldflags=-L/usr/local/opt/openssl/lib"

bundle install前に上記コマンドを流してみてください。

参照:
https://qiita.com/akiko-pusu/items/aef52b723da2cb5dc596

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[Day3]データベースへの接続準備

January 8, 2021
←前回:Day 2 プロジェクトの生成

今回はデータベースの準備をしました。
結論から言うと何も進みませんでした、、、
しかし、得たものは大きい?!

データベースの準備

Djangoにデフォで入っているSQLiteでやっても良かったのですが、参照しているサイトがMariaDBとPostgreSQLの解説をしていたため、そちらの設定を試してみました。

Postgresqlの接続

まず、Postgresqlを試してみました。

$ su postgres
#パスワード入力

これでできるらしいのですが、postgresqlのパスワードと、パスワード変更がわからなかったことと、コマンドsuが調べてもよくわからなかったので諦めました。

MariaDBの接続

MariaDBはMySQLと互換性があるらしく、大学でmySQL使用していたため、いけそうな気がしていました。
最初にターミナルにmySQLが入っていなかったのでhomebrewでmysqlをインストールするところから始めました。(コードは省略します)

で、以下のコードを入力すればできるらしいです。
{password}にはrootパスワードを入れます。

$ mysql -u root -p{password}

これでやったのですが、

mysql: [Warning] Using a password on the command line interface can be insecure.

と言う感じにエラーが出てしまいました。
rootの設定はシステム環境設定のディレクトリユーティリティから設定しているため間違えないと思います。

その後、いろいろ調べた結果、viコマンドでパスワードを外部ファイルから読み出すようにすれば出なくなるとの事だったので、tryしてみましたができませんでした。

おわりに

今回の学習時間は2時間しかとれなく、なかなか進むことができませんでした。
日記を見返すとPostgresqlがもう少しできる箇所があるかな?と思っています。
それでもダメなら、SQLiteで試してみます。

←前回:Day 2 プロジェクトの生成
→次回:Day 4 アプリケーションの生成

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Laravelでマイグレーション時にSQLSTATE[42000]: Syntax error or access violation: 1067 Invalid default valueとエラー時の解消法

はじめに

今回はわたしが遭遇したエラーと解消法についてご紹介したいと思います。
なかなか解決法が見つからなかったのですが、案外あっさりとした内容でした。備忘録の意味も含めて書きたいと思います。

-各バージョン
-laravel 6.x
-PHP 7.4.9
-mySQL 5.7.30

どのようなエラーが出たか

Laravelでマグレーションをした時に、発生したエラーです。
以下がエラー内容

Illuminate\Database\QueryException  : SQLSTATE[42000]: Syntax error or access violation: 1075 Incorrect table definition; there can be only one auto column and it must be defined as a key (SQL: create table `stock_cosmes` (`stock_id` bigint unsigned not null auto_increment primary key, `product` varchar(100) not null, `color` varchar(100) not null, `brand` varchar(100) not null, `price` int not null auto_increment primary key, `purchaseDate` date not null, `category` varchar(255) not null, `created_at` timestamp null, `updated_at` timestamp null) default character set utf8mb4 collate 'utf8mb4_unicode_ci')

  at /Users/yuzu/Desktop/jewelry/vendor/laravel/framework/src/Illuminate/Database/Connection.php:669
    665|         // If an exception occurs when attempting to run a query, we'll format the error
    666|         // message to include the bindings with SQL, which will make this exception a
    667|         // lot more helpful to the developer instead of just the database's errors.
    668|         catch (Exception $e) {
  > 669|             throw new QueryException(
    670|                 $query, $this->prepareBindings($bindings), $e
    671|             );
    672|         }
    673|

  Exception trace:

  1   PDOException::("SQLSTATE[42000]: Syntax error or access violation: 1075 Incorrect table definition; there can be only one auto column and it must be defined as a key")
      /Users/yuzu/Desktop/jewelry/vendor/laravel/framework/src/Illuminate/Database/Connection.php:463

  2   PDOStatement::execute()
      /Users/yuzu/Desktop/jewelry/vendor/laravel/framework/src/Illuminate/Database/Connection.php:463

  Please use the argument -v to see more details.
yuzunoMacBook-Air:jewelry yuzu$ -v
-bash: -v: command not found

そして、こちらが作成しようとしたテーブルです。

public function up()
    {
        Schema::create('stock_cosmes', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->string('product', 100);
            $table->string('color', 100)->nullable();
            $table->string('brand', 100)->nullable();
            $table->integer('price', 6)->nullable();
            $table->date('purchaseDate')->nullable();
            $table->string('category');
            $table->timestamps();
        });
    }

題名にあるエラー文でググってみたのですが、bigIncrementsは主キーにしなくてはいけないや、nullにできないといった解説が多く、わたしのエラー原因に一致するものが見つかりませんでした。
そこで、Laravelの公式サイトを読み直してみると、解決することができました!

解決法

とても初歩的な内容で恥ずかしいのですが、指定しているintegerには、第二引数を設定することができないというのが、今回のエラー原因でした。
integerにも字数制限をする場合には、length()で指定できるようです。

Laravel 6.x データベース:マイグレーション

以下、修正したテーブルです。

public function up()
    {
        Schema::create('stock_cosmes', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->string('product', 100);
            $table->string('color', 100)->nullable();
            $table->string('brand', 100)->nullable();
            $table->integer('price')->length(6)->nullable();
            $table->date('purchaseDate')->nullable();
            $table->string('category');
            $table->timestamps();
        });
    }

こちらで試したところ、問題なくエラーが解消されました!

おわりに

integerは第二引数を使用できない。とは書かれておらず、stringと同じ要領で使用してしまいましたが、改めて、公式サイトをきちんと読むことの大切さを思い知らされました。

同じようなエラーに悩まされている方のお力になれたら嬉しいです!

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む