技術めも

今月はがんばりました。

0.8.5をリリースしました。

https://github.com/shigenobu/ebonyrack/releases

MariaDBと謳っていますが、MySQLも可能なので、フリーのER図作成ツールとして、

少しでも、世の中で使ってもらいたいなと感じる出来になってきたかなと思っています。

とはいえ、マニュアルも古いので書き換えないとですね。。

0.8.1〜0.8.5の変更内容は以下のとおりです。

なお、0.8.5で、ローカルのSQLITEの一部の型を変更したので、

旧バージョンでJSONをWRITEしてから、新バージョンでJSONをREADしてもらえればと思います。

（検索の調整）

検索ボックスを画面の左下に出すようにしました。

enterで次へ、shift+enterで前へ、なども対応しています。

フォーカスの遷移は、単語ごとではなく、オブジェクトごとになってます。

合わせてサイドのスライダーも連動するようになってます。

個人的には結構いい感じかなと満足の出来です。

（外部キーのIMPORT）

ALTER TABLEによる外部キーのIMPORTに対応し、

さらにCREATE TABLEに含まれる外部キーのIMPORTにも対応しました。

かなり厄介でした。。

ebonyrackの仕様として、外部キー同士の型が一致していないとダメとしているのですが、

それはIMPORTにも適用させていただきました。

（テーブルとシーケンスの位置・色の一括調整）

タイトルの通り、一括で位置と色を調整できるようしました。

例によって、エクセルからの貼り付け対応ですね。（正確にはタブ区切り）

上記以外にも、

フォーカスがあたっているオブジェクトにenter押下で編集画面を上げるようにしたり、

ちょこちょこ使い勝手の修正をいれてます。

そして、やるやる言ってた外部キーと検索ができたので、

改めて次の課題を備忘録的に書いておきます。

• VIEW/FUNCTION/TRIGGER/PROCEDURE
• テストデータ生成
• IMPORT時の自動配置調整
• パフォーマンス調整

JAVA21用にも書き換えないとですね。

1.0.0も近づいてきたので（特に意味はないですが）、頑張ろうかと思います。

以上

MariaDB 11.8 が今月GAリリースされました。

https://mariadb.com/docs/release-notes/mariadb-community-server-release-notes/mariadb-11-8-series/what-is-mariadb-118

今回はLTSなので、2028年6月までの長期サポートとなります。

公式を見ていただければわかりますが、流行りのVECTOR型とか色々入ってます。

基本的には、STSである11.5〜11.7の変更がそのまま取り入れられている感じですね。

いろいろ、見返してみると、MariaDBは10.0の時代から、

DELETE〜RETURNING

があったんですね。。初めて知りました。

https://mariadb.com/docs/server/reference/sql-statements/data-manipulation/changing-deleting-data/delete

RETURNINGは、

• INSERT RETURNING
• REPLACE RETURNING
• DELETE RETURNING

ってことで、3つあるようです。

REPLACEはちょっと色々あるのであんまり使わないですが、

DELETE RETURNINGはデータの退避とかにも使えそうですね。

で、自分のつくっているmagentadeskもv0.8.0でMariaDB 11.8に対応しました。

https://github.com/shigenobu/magentadesk

※すいません、VECTOR型は未対応です。。

MySQLも8.4系をサポートしようと思ったのですが、

magentadeskが差分検出時に行うクエリーで以下のようなエラーが出るようになりました。

[ERROR] [MY-010211] [Server] Got error 124 when reading table '/tmp/#sql1_10_5e'

8.0.42などの8.0系ではでないのですが、8.4から急に出るようになりました。

原因は今の所不明です。。

なにかわかったらまたブログに書こうかなと。

とりあえず、今回は以上。

EOLを迎えて1年立ちましたが、未だにcentos7は使われているはず。

valutがアーカイブレポジトリを提供しており、これを使えばまだしばらくは大丈夫なはず。

（参考）

https://qiita.com/ragi/items/9225f307ea3b38ba1fa6

とはいえ、アリババもレポジトリを提供していたりします。

https://developer.aliyun.com/mirror/centos

上記を参考に、centos7の場合は、

# mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.backup
# wget -O /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo

てな感じで、レポジトリを上書きできます。

ただ、baseurl記載の

• mirrors.aliyuncs.com
• mirrors.cloud.aliyuncs.com

がアクセスできないことがあるので、この2行は削除しておくといいかもしれません。

あとは、

# yum clean all

してから、色々操作ができるはず。

古いサーバにどうしても追加モジュールを入れる必要があり、

このような方法を取ったことがあったので、記載しておきます。

valutもそうですが、アリババのレポジトリもいつまで生きているかわからないので、

なるべく早くOS移行をしましょう。

以上

しばらくぶりの投稿となってしまいました。。

ebonyrack の 0.8.0 をリリースしました。

https://github.com/shigenobu/ebonyrack/releases

0.7.1 – 0.8.0 での主な変更点は以下となります。

なお、0.7.2 でローカルデータベースの変更が入っているので、

旧バージョンでJSONにWriteしてから、新バージョンでJSONをReadしてください。

（外部キーとコネクター関連の修正）

外部キーの参照される側のカラム（親テーブルのカラムといったほうがいいか）は、

主キーもしくはユニークキーであるようにしました。

もともと外部キーというのはそういうものですが、MySQL系はこの制約が緩く、

要はなんでもOKだったのです。

しかし、MySQL8.4から上記のように参照される側のカラムについて厳格になったので、

それに合わせた修正を行いました。

（※今まで緩すぎたのです。本来はこう有るべきなのです。）

（パフォーマンス調整およびオブジェクトの移動不具合修正）

アウトライン（左側の小さい画面）の描画回数が大きく、

CPU使用率が高かったので、500ミリ秒間は再描画しないようにしました。

また、オブジェクトを移動する際、マウスを押してから離す時間が長いと、

(0,0) に移動してしまう不具合があったので、修正しています。

（エクスポートの履歴保持）

DDLとクラスファイル出力時に、

出力条件（対象テーブルの設定とか、ファイルをどこに出力するか）を一定数保持して、

その条件を再度利用できるようしました。

何度もエクスポートしていると、条件を毎回入力しないといけないので、

この煩わしさのために対応しました。

実際に、プログラムファイルを出力することが多く、

対象テーブルの絞り込みやスキーマなどの出力条件を再利用できる形になって楽になりました。

やるやるいっている、検索の修正、VIEWの対応、外部キーパースなどは全く手を付けていないです。

ebonyrackは実案件でも使っているのですが、VIEWとか、外部キーパースは使わないですよね。。

というわけで、実際に使っているうちに遭遇した不具合とか、不都合の修正を行っていました。

そろそろ、JAVA21にしようかなというフェーズに来ています。

1.0.0 には21にしたいかなと。。

以上

誰も見ていないこのブログを立ち上げ、2024年11月で11年目となります。

丸10年ですね。

約200弱の記事を書いてきましたが、今見直してみると過去のやつは不十分なものもあるなと感じています。

さくらのVPSのCentos7で運用していますが、そろそろリプレイスが必要だな、とも思いつつ。。

この10年振り返ってみると、年々仮想化が強くなり、ITの巨人の肩にのる割合が増えている感じがします。

今後もこの流れは続くのかなとは思いますが、やはり銀の弾丸はないものなので、

特性を把握し、うまく利用していくための学習・情報収集・試行が必要なのかなと思います。

一方で、ビジネスとしては、小さいシステムが淘汰されていくのだろうかと感じつつ、

小さいシステムをちゃんと構築する経験を踏めなくなっていくのは、

今後の人材育成においても懸念に感じています。

確実なことはわからないのが世の常かもしれませんが、

このブログを少しでも長く続けられればいいなと今は思うばかりです。

以上

0.7.0をリリースしました。

https://github.com/shigenobu/ebonyrack/releases

今月はがんばった。。

0.6.8、0.6.9、0.7.0での対応内容は以下となります。

（依存ライブラリの最新化）

一定サイクルでやらないとね。

（HTMLの修正）

HTMLのsvgにtextを埋め込み、検索可能としました。

FONTを合わせないと、検索のときにずれてしまうので、

FONTもGoogleFontから取得するよう、HTMLも修正しています。

（検索機能）

CTR+Fで検索BOXが出現するようになりました。

workspace上で見えているテキストに対して検索し、

見つかった場合は、ワードをハイライトするとともに、

ワードを含んでいないオブジェクトを目立たないようにしました。

とはいえ、改善の余地がある感じではあります。

（サイドとワークスペースの連動修正）

これまではサイドのオブジェクト名をクリックすると、

ワークスペースの該当オブジェクトに移動し、フォーカスさせていました。

これを、クリックまたは十字キー選択では、該当オブジェクトに移動するにとどめ、

ダブルクリックまたはENTERキーで、フォーカスさせるようにしました。

これは検索時にサイドのオブジェクト名を目立たせないようにしたため、

クリックでフォーカスを当てると操作性が悪くなるためです。

また、ワークスペース上でフォーカスを持っているオブジェクトに対して、

サイドが連動して選択状態になるようにしています。

今回の検索機能で、指定のオブジェクトのみを目立たせることは不要になったので、

予定を修正して、以下のプランで今後を進めようかと思います。

• ANTLRによる外部キーパース
• VIEWの対応
• 検索の改善（小さな表示スペースで、前・次で飛べるようなイメージ）
• テストデータ作成

テストデータ用のINSERT文作成というのが正確ですが、開発中にあると便利だなと思いました。

他のツールでもあったりするようなので、優先度上げてやってみようかなと思ってたりします。

以上

mysqlで連番を生成しようとすると以外と難しいです。

再起CTEなんかでやらないといけないかなと。

mariadbではsequence storage engineの機能を使うと、とてもかんたんです。

https://mariadb.com/kb/en/sequence-storage-engine

に書いてあるとおりです。

↓の感じですね。

> select * from seq_1_to_10;
+-----+
| seq |
+-----+
|   1 |
|   2 |
|   3 |
|   4 |
|   5 |
|   6 |
|   7 |
|   8 |
|   9 |
|  10 |
+-----+

なんで連番を生成したいかというと、歯抜けが許されない場合があるからですね。

たとえば、↓のような状況だったとします。

> CREATE TABLE `active` (
  `ymd` date NOT NULL,
  `cnt` int(11) NOT NULL,
  PRIMARY KEY (`ymd`)
);

> select * from active;
+------------+-----+
| ymd        | cnt |
+------------+-----+
| 2024-10-01 |  10 |
| 2024-10-02 |   7 |
| 2024-10-04 |  11 |
+------------+-----+

見てのとおり、「2024-10-03」のデータがありません。

ここで連番テーブルとLEFT JOINすることで、

「2024-10-03」を「0」として計上できます。

↓の感じですね。

> with
t as 
(
  select date('2024-10-01') + interval seq day as ymd from seq_0_to_3
)
select
  t.ymd as ymd,
  coalesce(active.cnt, 0) as cnt
from
  t
  left outer join
  active
  on t.ymd = active.ymd
order by
  t.ymd
;
+------------+------+
| ymd        | cnt  |
+------------+------+
| 2024-10-01 |   10 |
| 2024-10-02 |    7 |
| 2024-10-03 |    0 |
| 2024-10-04 |   11 |
+------------+------+

まあ、今更ですが、意外と連番生成は求められるので、

mariadbであるなら、sequence storage engineをつかうと楽ですよ、ってことですかね。

以上

0.6.7をリリースしました。

https://github.com/shigenobu/ebonyrack/releases

0.6.5、0.6.6、0.6.7での対応内容は以下となります。

（DDLの出力時にスキーマ名を指定可能）

これは、「use 〇〇;」をDDLファイルの先頭に入れるためです。

（オブジェクトのCTR+CとCTR+Vの対応）

オブジェクト（テーブル、シーケンス、ノート）は、今までも右クリックでコピー＆ペイストができたのですが、

CTR+CとCTR+Vの操作に対応しました。

CTR+Vでは、最も新しいコピー元を貼り付けます。

（テーブルのカラムへの挿入貼り付けとDELキーによる行削除の対応）

テーブル内のカラム一覧に、挿入貼り付けを対応しました。

これは大量のカラムを登録したいときに、エクセルなどで予め準備しておくことで、

一気に挿入可能となるものです。

「Column name」のセルの背景が薄い赤になっているので、

ここに対してCTR+Vで挿入貼り付けとなります。

また、DELキーで複数行の削除が可能となります。

（テーブルおよびシーケンス一覧の追加）

「Edit」のメニューに追加しています。

テーブルやシーケンスの情報を一括更新可能です。

テーブルでは、カラムグループとパーティションも編集可能です。

薄紫のセルに対して、CTR+Vをすることで、上書き貼り付けが可能です。

エクセルで変換情報を用意しておき、貼り付けるとよいかなと思います。

また、パーティションを一気に付与するなどができるようになっています。

（パーティションってあとでやる場合も多いので）

（複数オブジェクトの移動）

今まではオブジェクト1つずつしか移動できませんでしたが、

SHIFT＋左クリックで対象を複数選択し、移動することができるようになりました。

オブジェクトの重なり合いが少し微妙な部分はありますが、操作性の向上は図れています。

JTableのセル操作の向上が難しく、エクセルとの併用のほうが良いかと思い、

貼り付けなどを対応している感じになってます。

今後ですが、

• 特定の名称パターンのオブジェクトのみを表示する（例えば「shop」が含まれているテーブルだけ表示するなど）
• VIEWの対応

あたりを優先的に考えてます。

その他としては、

• 外部キーのDDLを読めるようにする（ANTLRのパースで、自前で生成したものくらいは読めるようしたいかな）
• FUNCTION/TRIGGER/PROCEDUREの追加
• 検索機能
• データ作成機能

あたりを考えています。

以上

MariaDBの同一ホスト間のデータ同期システムとして作っていたmagentadeskなのですが、

0.7.0のリリースで、MySQL 8.0.31 と 8.0.32 の対応を入れました。

https://github.com/shigenobu/magentadesk

なんで今までやらなかったかというと、

• テーブルの解析でのinformation_schemaの格納のされ方が微妙にMariaDBとMySQLで異なる
• MySQLではEXCEPTが8.0.31までなかった
• MariaDBのdynamic columnに相当する機能がMySQLでは賄えるか不安だった
• シーケンスがないのをどうするか

といったところでしたが、MySQL 8.0.31でEXCEPTが入ったので、

本腰入れて対応してみました。

やってみて色々大変でした。

なかでもUNIONの動作がおかしくて、無理やりやる感じでした。

MariaDBとMySQLでのUNIONの動作を見てみます。

まず以下のデータを用意します。

> select * from base;
+------+
| c    |
+------+
|    1 |
|    2 |
+------+

> select * from compare;
+------+
| c    |
+------+
|    1 |
|    3 |
+------+

次にこんなSQLを投げます。

with 
t1 as 
(
  select * from base
  except
  select * from compare
),
t2 as 
(
  select * from compare
  except
  select * from base
),
tt1 as 
(
  select 
  json_object('c', t1.c) as b,
  json_object('c', t2.c) as c
  from
  t1
  left outer join
  t2
  on t1.c = t2.c
),
tt2 as 
(
  select 
  json_object('c', t1.c) as b,
  json_object('c', t2.c) as c
  from
  t1
  right outer join
  t2
  on t1.c = t2.c
),
t as 
(
  select * from tt1
  union
  select * from tt2
)
select * from t;

ちょっとややこしいのですが、

MariaDBとMySQLの結果を見てみます。

(MariaDB)

+-------------+-------------+
| b           | c           |
+-------------+-------------+
| {"c": 2}    | {"c": null} |
| {"c": null} | {"c": 3}    |
+-------------+-------------+

(MySQL)

+-------------+-------------+
| b           | c           |
+-------------+-------------+
| {"c": 2}    | {"c": null} |
| {"c": 1}    | {"c": 1}    |
| {"c": null} | {"c": 3}    |
+-------------+-------------+

いやー、MySQLの結果がおかしいですよね。これ仕様なのか？

EXCEPTで除いている筈なのに。。

MySQLのUNIONは結構昔から不具合あるようで、

なんかこうなってくると複雑な集計クエリーを投げるのがちょっと怖い感じもしますね。

現状では、気をつけましょうとしかいいようがないですが。。

以上

Rolling release（つまりSTS）なのですが、2024年8月にMariaDB11.5がGAになりました。

（参考）

https://mariadb.com/kb/en/changes-improvements-in-mariadb-11-5

気になっていたtimestamp拡張が入り、

2106-02-07 06:28:15 UTC

までtimestampを扱えるようになりました。

実際に、10.11と11.5で比較してみました。

なお、timezoneは日本にしています。

MariaDB 10.11

-- int max
> set timestamp = 2147483647; select now();
Query OK, 0 rows affected (0.000 sec)

+---------------------+
| now()               |
+---------------------+
| 2038-01-19 12:14:07 |
+---------------------+

-- int max + 1
> set timestamp = 2147483648; select now();
ERROR 1231 (42000): Variable 'timestamp' can't be set to the value of '2147483648'
+---------------------+
| now()               |
+---------------------+
| 2038-01-19 12:14:07 |
+---------------------+

-- unsigned int max
> set timestamp = 4294967295; select now();
ERROR 1231 (42000): Variable 'timestamp' can't be set to the value of '4294967295'
+---------------------+
| now()               |
+---------------------+
| 2038-01-19 12:14:07 |
+---------------------+

-- unsigned int max + 1
> set timestamp = 4294967296; select now();
ERROR 1231 (42000): Variable 'timestamp' can't be set to the value of '4294967296'
+---------------------+
| now()               |
+---------------------+
| 2038-01-19 12:14:07 |
+---------------------+

見てもらえればわかりますが、

2038-01-19 12:14:07

が限界となっています。

MariaDB 11.5

-- int max
> set timestamp = 2147483647; select now();
Query OK, 0 rows affected (0.001 sec)

+---------------------+
| now()               |
+---------------------+
| 2038-01-19 12:14:07 |
+---------------------+

-- int max + 1
> set timestamp = 2147483648; select now();
Query OK, 0 rows affected (0.001 sec)

+---------------------+
| now()               |
+---------------------+
| 2038-01-19 12:14:08 |
+---------------------+

この時点で、超えましたね。

-- unsigned int max
> set timestamp = 4294967295; select now();
Query OK, 0 rows affected (0.001 sec)

+---------------------+
| now()               |
+---------------------+
| 2106-02-07 15:28:15 |
+---------------------+

-- unsigned int max + 1
> set timestamp = 4294967296; select now();
Query OK, 0 rows affected, 1 warning (0.001 sec)

+---------------------+
| now()               |
+---------------------+
| 2106-02-07 15:28:15 |
+---------------------+

> show warnings;
+---------+------+---------------------------------------------------+
| Level   | Code | Message                                           |
+---------+------+---------------------------------------------------+
| Warning | 1292 | Truncated incorrect timestamp value: '4294967296' |
+---------+------+---------------------------------------------------+

unsigned int の最大値を超えるとwaningはでましたが、

2106-02-07 15:28:15

まで最大値が伸びているようです。

そもそも、timestampをunsignedにしたというのは、ドライバー影響を抑えるという名目だったかなと。

で、実際に以下のようにデータを入れてみます。

CREATE TABLE `t1` (
  `c1` timestamp NULL DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
insert into t1 values ('2106-02-07 15:28:15');
> select * from t1;
+---------------------+
| c1                  |
+---------------------+
| 2106-02-07 15:28:15 |
+---------------------+

これをPHPとC#（mysqlconnector）で取得してみたところ、

2106-02-07 15:28:15

が取得できることは確認できました。

MySQL側も同様の対応をしてくれると嬉しいです。

以上