- 投稿日：2020-11-27T17:30:05+09:00
SequelPro難民の皆様へお知らせです
はじめに
MySQL等を触る際にとても便利なDBクライアントツール
皆さんは何を使っていますでしょうか？僕は今まで「SequelPro」を使っていました。
SequelProの更新が止まった
今まで沢山お世話になったSequelProですが、ある日からパッタリと更新を辞めました。
製作者に何があったのかは分かりませんが、未解決の課題は積もっていき1000を超える量となってしまい、本格的に乗り換えを検討が必要となりました。
SequelPro難民を救うべく立ち上がった開発者達
SequelProが非アクティブになってから何年も経った時、ついにコミュニティが立ち上がりました。
SequelProをフォークして後継となるSequelAceを作りました。
あくまでフォークしたものなのでライセンスはSequelProに帰属します。
License
Copyright (c) 2020 Moballo, LLC. All rights reserved. Forked from Sequel Pro: Copyright (c) 2002-2019 Sequel Pro & CocoaMySQL Teams. All rights reserved.
Sequel Ace is free and open source software, licensed under MIT. See LICENSE for full details.開発も活発に行われているため、SequelProユーザーにはとても嬉しいニュースですね。
使用感
使用感はSequelProとほとんど変わりません。
最近流行りのダークモードにも対応しており、UIの洗練された印象です。
まさにSequelProの上位互換という感じですね。
ダウンロード方法
ダウンロードはAppStoreから可能です。
また、以下のコマンドでHomebrew経由でダウンロードすることも可能です。
$ brew cask install sequel-aceまとめ
CLIの魅力もありますが、DBクライアントツールは作業効率を大きく向上してくれる大切な要素だと思います。
ぜひお気に入りのDBクライアントツールを導入して効率的に開発を行っていきましょう〜！
- 投稿日：2020-11-27T17:30:05+09:00
ついにSequelProの後継が出たよ！
はじめに
MySQL等を触る際にとても便利なDBクライアントツール
皆さんは何を使っていますか？僕は今まで「SequelPro」を使っていました。
SequelProの更新が止まった
今まで沢山お世話になったSequelProですが、ある日からパッタリと更新を辞めました。
製作者に何があったのかは分かりませんが、未解決の課題は積もっていき1000を超える量となってしまい、本格的に乗り換えを検討が必要となりました。
SequelPro難民を救うべく立ち上がった開発者達
SequelProが非アクティブになってから何年も経った時、ついにコミュニティが立ち上がりました。
SequelProをフォークして後継となるSequelAceを作りました。
あくまでフォークしたものなのでライセンスはSequelProに帰属します。
License
Copyright (c) 2020 Moballo, LLC. All rights reserved. Forked from Sequel Pro: Copyright (c) 2002-2019 Sequel Pro & CocoaMySQL Teams. All rights reserved.
Sequel Ace is free and open source software, licensed under MIT. See LICENSE for full details.開発も活発に行われているため、SequelProユーザーにはとても嬉しいニュースですね。
使用感
使用感はSequelProとほとんど変わりません。
最近流行りのダークモードにも対応しており、UIがさらに洗練された印象です。
まさにSequelProの上位互換という感じですね。
ダウンロード方法
ダウンロードはAppStoreから可能です。
また、以下のコマンドでHomebrew経由でダウンロードすることも可能です。
$ brew cask install sequel-aceまとめ
CLIの魅力もありますが、DBクライアントツールは作業効率を大きく向上してくれる大切な要素だと思います。
ぜひお気に入りのDBクライアントツールを導入して効率的に開発を行っていきましょう〜！
- 投稿日：2020-11-27T16:33:08+09:00
CentOS8.2のMySQL8.0でユーザーにGRANT設定する手順
../ VPSサーバー（CentOS8.2）でMySQL 8.0を使用している。特定のデータベースに特化したユーザーを登録し、DBへのアクセス権限(GRANT)を設定する手順をメモしておく。
例として、
kankeriというデータベースに管理者としてkadminと一般ユーザーとしてkuserを登録することにする。kadminにはALL PRIVILEGESを設定し、kuserには一般的なCRUD操作のみを許可する。MySQL 8.0では、認証回りが強化されたため、userテーブルからpasswordカラムがなくなっている点に注意すること。（正確には、暗号化されたパスワードはauthentification_stringというカラムに移されている。）$ mysql -uroot -p mysql > use mysql; > create database kankeri; // まず、kankeriデータベースを生成 > use kankeri; > show variables like 'char%'; > # delete from user where user='kadmin'; > # delete from user where user='kuser'; > # SET PASSWORD FOR root@localhost=PASSWORD('***'); > CREATE USER kadmin@localhost IDENTIFIED BY '***'; // kadmin追加 > CREATE USER kuser@localhost IDENTIFIED BY '***'; // kuser追加 > GRANT ALL PRIVILEGES ON kankeri.* TO kadmin@localhost; // kadminの権限 > GRANT DELETE,INSERT,SELECT,UPDATE ON kankeri.* TO kuser@localhost; // kuserの権限 > select host,user,plugin from user; +-----------+------------------+-----------------------+ | host | user | plugin | +-----------+------------------+-----------------------+ | localhost | kadmin | mysql_native_password | | localhost | kuser | mysql_native_password | | localhost | mysql.infoschema | caching_sha2_password | | localhost | mysql.session | caching_sha2_password | | localhost | mysql.sys | caching_sha2_password | | localhost | root | mysql_native_password | +-----------+------------------+-----------------------+ > flush privileges; > exitkadmin、kuserともパスワードの認証方式は、mysql_native_passwordになっている。この設定は、/etc/my.cnf.d/mysql-default-authentication-plugin.cnfで指定したものに従っている。
以下のような手順で、権限が適切に機能しているかチェックしておこう。
$ mysql -uroot -p kankeri > create table dummy1 (id int, name varchar(50)); > insert dummy1 values(10,’梶井基次郎’); // kadminは、kankeriデータベース以外にはアクセスできない $ mysql -ukadmin -p kankeri > create table dummy2 (id int, name varchar(50)); > insert dummy2 values(20,’中島敦’); > use mysql; ERROR 1044 (42000): Access denied for user 'kadmin'@'localhost' to database 'mysql' // kuserは、kankeriデータベース以外にはアクセスできない // kuserは、create tableなどスキーマに関する操作はできない $ mysql -ukuser -p kankeri > create table dummy3 (id int, name varchar(50)); ERROR 1142 (42000): CREATE command denied to user 'kuser'@'localhost' for table 'dummy3' > insert dummy1 values(30,’檸檬’); > insert dummy2 values(40,’山月記’); > select * from dummy1; > select * from dummy2;以上
../
- 投稿日：2020-11-27T15:00:28+09:00
DockerでGolang+mysqlの環境を立ち上げようとしたときに発生したミス＆対処法
環境構築で８時間程度溶かしてしまったわけなのですが（８時間はもしかしたらいいほうかもしれない？）、そのときの対処法についてまとめておきます。結局対処するのに必要だったのはコード２行分の編集だったのはちょっと辛いですね、、、
net::ERR_EMPTY_RESPONSEに対してmain.goでの編集
net::ERR_EMPTY_RESPONSEがひたすら帰ってきていたのを、main.goで以下のように編集したら直りました。
HTTP_HOST,HTTP_PORTなどは.envから読み出している環境変数です。失敗:
r.Run(os.Getenv("HTTP_HOST") + ":" + os.Getenv("HTTP_PORT")) // for local成功:
HTTP_HOSTの部分がどうやらいらなかったらしいです、どうしてかはわかりません、、、
こちらの方の記事を参考にさせていただきました。Dockerコンテナ上で動くGinサーバーにアクセスできないエラーの解決法r.Run(":" + os.Getenv("HTTP_PORT")) // for local or r.RUN(":8080")mysqlのpanicに対しての
sql_handler.goの編集こちらのstackoverflowが役に立ちました：panic: dial tcp 127.0.0.1:3306: connect: connection refused
失敗:
db, err = gorm.Open("mysql", user+":"+password+"@tcp("+host+":"+port+")/"+database+"?parseTime=true&loc=Asia%2FTokyo")成功:
dockerコンテナのホストとポートではなく、名前で指定してあげると見事にデータベースにつながりました。docker-composeはdockerが生成したネットワークを使用するため、コンテナの名前をそのまま利用できるらしいです。でもどうして上記だと失敗するのかはよくわかりません、、、db, err = gorm.Open("mysql", user+":"+password+"@tcp(mysql_docker_container_name)/"+database+"?parseTime=true&loc=Asia%2FTokyo") # mysql_docker_container_nameのところをクオテーションなしでそのまま自分のdockerコンテナの名前を入れてください
- 投稿日：2020-11-27T11:59:34+09:00
CentOS8.2でMySQL8.0コンソールから日本語入力できない問題の回避策
../ VPSサーバー（CentOS8.2）にMySQL 8.0をインストールして、character_setを以下のように設定して利用しようと考えた。
mysql> show variables like 'char%'; +--------------------------+----------------------------+ | Variable_name | Value | +--------------------------+----------------------------+ | character_set_client | utf8 | | character_set_connection | utf8 | | character_set_database | utf8 | | character_set_filesystem | binary | | character_set_results | utf8 | | character_set_server | utf8 | | character_set_system | utf8 | | character_sets_dir | /usr/share/mysql/charsets/ | +--------------------------+----------------------------+しかし、GNOMEデスクトップでMySQLコンソールを開いて、
mysql>のプロンプトになっている状態で、日本語が入力できないという現象が起きた。正確には、日本語は入力でき、かな漢字変換もできるが、それをenterキーで確定した後で、変換された文字列を取り込めていない。入力した日本語の文字列も変換された日本語の文字列も、すっかり消えるのである。MySQLコンソールで日本語を入力する場面は、INSERT文やUPDATE文を実行したいときである。このままでは不便である。原因分析
MySQLコンソールにバグがあるのか、日本語版IMEであるibus-kkcにバグがあるのか、MySQLコンソールとibus-kkcの相性の問題なのかは判断できない。CentOS6.xのときには、IMEはibus-anthyであったが問題はなく、MySQLコンソールで日本語が入力できている。私のところでは、CentOS6.2のサーバーも現役で稼働中なので、確認してみたが問題はなかった。Anthyは2001年にリリースされ、libkkcは2013年にリリースされたそうだ。CentOSでは、2014年にリリースされたCentOS7からlibkkcが採用されたようだ。私はCentOS7は未経験なので、状況を把握できていなかった。Fedoraもlibkkcを採用しているようで、同じ症状はFedoraでも起きているそうだ。
※ibus-kkcやibus-anthyはCentOSのIMEのインタフェースであり、本体のかな漢字変換機能がlibkkcやAnthyである。localeの設定だけでは解決しないし、MySQLの[client]のdefault-character-setの設定でも解決しないことが分かった。localeは、UTF-8に設定されていれば問題ない。UTF-8でもutf8でもいい。大文字小文字やハイフンの有無は関係ない。
$ locale LC_ALL=ja_JP.UTF-8 LANG=ja_JP.UTF-8MySQLの[client]のdefault-character-setは、utf8でもutf8mb4でも関係ない。以下は、utf8mb4を設定した場合である。どちらで設定してもかな漢字変換は機能しているが、その後のMySQLコンソールでibus経由で変換された文字列を取り込む際の挙動がおかしいのである。
$ vi /etc/my.cnf.d/client.cnf [client] # default-character-set= # default-character-set=utf8 default-character-set=utf8mb4回避策
MySQLコンソールか日本語版IMEであるibus-kkcにバグがあるのだろうが、経験的に回避策があることは掴めた。非常におかしな挙動なのだが、client.cnfでdefault-character-setの行をコメントアウトするとうまくいく。つまり、以下のように記述する。いや、[client]でdefault-character-setの記述をしないと言った方がいいか。
$ vi /etc/my.cnf.d/client.cnf [client] # default-character-set= # default-character-set=utf8 # default-character-set=utf8mb4mysqldを再起動して、MySQLコンソールで再接続してみる。show variablesで確認すると、client,connection,resultsが初期状態でutf8mb4になる。serverは、私のところではutf8で使いたいので、そこは譲れない。この状態で、日本語が入力でき、INSERT文にも日本語が使えるようになる。
mysql> show variables like 'char%'; +--------------------------+----------------------------+ | Variable_name | Value | +--------------------------+----------------------------+ | character_set_client | utf8mb4 | | character_set_connection | utf8mb4 | | character_set_database | utf8 | | character_set_filesystem | binary | | character_set_results | utf8mb4 | | character_set_server | utf8 | | character_set_system | utf8 | | character_sets_dir | /usr/share/mysql/charsets/ | +--------------------------+----------------------------+ mysql> insert dummy1 values(10,'梶井基次郎'); Query OK, 1 row affected (0.01 sec) mysql> select * from dummy1; +------+-----------------+ | id | name | +------+-----------------+ | 10 | 梶井基次郎 | +------+-----------------+ 1 row in set (0.00 sec)では、client.cnfで[client]のdefault-character-set=utf8mb4を明示的に設定してみるとどうだろう。以下の感じである。
$ vi /etc/my.cnf.d/client.cnf [client] # default-character-set= # default-character-set=utf8 default-character-set=utf8mb4明示的にdefault-character-set=utf8mb4を設定して、mysqldを再起動して、MySQLコンソールで再接続してみる。show variablesで確認すると、前述のものと全く同じでclient,connection,resultsがutf8mb4になっている。
mysql> show variables like 'char%'; +--------------------------+----------------------------+ | Variable_name | Value | +--------------------------+----------------------------+ | character_set_client | utf8mb4 | | character_set_connection | utf8mb4 | | character_set_database | utf8 | | character_set_filesystem | binary | | character_set_results | utf8mb4 | | character_set_server | utf8 | | character_set_system | utf8 | | character_sets_dir | /usr/share/mysql/charsets/ | +--------------------------+----------------------------+しかし、日本語は入力できないのである。さっぱり分からない。character_setを見ただけでは差異はないが、内部的に挙動が異なっているのだ。とりあえずの回避策としては、[client]のdefault-character-setを明示的に設定しないで、初期値としてutf8mb4が選択された場合のみ、日本語が入力できるということはわかった。
default-character-set=utf8で利用したい場合
[client]のdefault-character-set=utf8を設定して利用したい場合、MySQLコンソールからは日本語が入力できないので、別の回避策が必要である。私は、sourceコマンドで読み込みながら、INSERT文やUPDATE文を実行するのがいいかと思う。例えば、作業ディレクトリにwork/temp.sqlといったテキストファイルを作成して、同時に開いて、編集と実行を繰り返す。
work/temp.sql# create database dummy1 (id int, name varchar(50)); # insert dummy1 values (10,'梶井基次郎'); insert dummy1 values (20,'中島敦');MySQLのコンソールからは、適宜、sourceコマンドでファイルを読み込めばいい。編集する、読み込む、編集する、読み込むの繰り返しでなんとかなるだろう。
$ mysql -uroot -p dummydb; mysql> source work/temp.sql; mysql> select * from dummy1; +------+-----------------+ | id | name | +------+-----------------+ | 10 | 梶井基次郎 | | 20 | 中島敦 | +------+-----------------+以上
../
- 投稿日：2020-11-27T11:37:21+09:00
CakePHP4 クエリビルダでの AVG と ROUND のやり方
AVG で平均を取った後の、小数点以下の四捨五入についてのコードが公式含め見当たらなかったので書き残しておきます。MySQL前提です。
例えば以下の要件を満たす場合です。
- 商品の評価の平均値
- 小数点第一位で四捨五入したい
コード
$query = $this->Products->find(); $result = $query ->select([ 'average_evaluation_rating' => $query->func()->round([$query->func()->avg('Products.evaluation'), 1]), ]) (以下略)解説
MySQLだと以下のように書くところを
ROUND(AVG(Products.evaluation), 1)CakePHP4 だと以下のように書きます。
$query->func()->round([roundしたい内容, 四捨五入する小数点の位置])AVG も関数を使って書くべきなので、round したい内容に
$query->func()->avg('Products.evaluation')と書いています。
実行されるクエリ
SELECT (round(AVG(Products.evaluation), '1')) AS average_evaluation_rating FROM products Products (以下略)