技術めも

MariaDB 12系の初LTSである、12.3がリリースされました。

https://mariadb.com/docs/release-notes/community-server/12.3/mariadb-12.3-changes-and-improvements

12系を見て、ちょっときになった点を挙げておきます。

（CTEのUPDATE/DELETE対応）

これまではINSERTだけだったので、ちょっとうれしい。

INSERTと違って、UPDATE/DELETEは最後に書くみたいです。

（MySQLのcaching_sha2_passwordとの互換）

これも嬉しいですね。これまでも通っていたのですが、完全な互換ではなかったようです。

（Optimizer Hints の導入）

あんまり使うことはないのですが、集計クエリーでちょっとオプティマイザを変えたいなと思うときは便利です。

（外部キーの制約名の一意性変更）

外部キーのConstraintNameは、データベース内で一意である必要があったのですが、

今後はテーブル内一意でよいそうです。

データベース一意だと、REPLACEとかで邪魔になるからだそうです。

（InnoDBにおけるWALログとバイナリログの統合）

これはすごいですね。内部XAトランザクションが省略されるので、かなりパフォーマンスアップになると思います。

色々制約はあるようですが、以下が詳しく解説してくれています。

https://blog.s-style.co.jp/2026/04/15832

（REPEATABLE READの挙動変更）

私は、普段は「READ-COMMITTED」で、「for update」などのロックを使ってしまうので、

あんまり関係ないですが、「REPEATABLE-READ」を使っている人は要注意です。

というわけで、ちょっと検証してみました。

1．transaction_isolationが「REPEATABLE-READ」で、innodb_snapshot_isolationが「0」

従来の「REPEATABLE-READ」の挙動です。

2．transaction_isolationが「REPEATABLE-READ」で、innodb_snapshot_isolationが「1」

12.3のデフォルトの挙動です。

というように、挙動が変わります。

これは個人的には正しい挙動かと思います。

とはいえ、これを理解して、ロックを回避するというのを開発側に伝えるのもちょっと難しい気もします。

ロックがない分散DBなんかも、こんな形でエラーを起こすことはあると思うので、どっかで役に立つかもしれません。

ちなみに、私の作っているmagntadeskでは、0.9.3で、MariaDB12.3に対応しています。

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

以上

popos24にアップグレードし、1ヶ月ほど立ちました。

前回の記事で記載していた日本語問題はだいぶ改善されており、

毎週、いや毎日のようにcosmic周りの改善が入っています。

cosmic-terminalも問題なく日本語が入るようになりました。（なぜか少しフォントが大きいのが気になるが。）

自作のebonyrackというjavaのGUIアプリケーションは、まだまだwaylandでは不具合が多いですかね。。

JBR（Jetbrains Runtime）でも試してみましたが、しばらくは時間かかりそうですね。

とはいえ、cosmicデスクトップはだんだんいい感じになってきました。

今後も期待しています。

余力ができたら、system76からPC買いたいな、とは考えています。

以上

数年使っていた popos 22 から、2025年12月にリリースされた 24 にアップグレードしました。

22からのアップグレード自体は、2026年2月に配信されていたので、3ヶ月様子見でした。

アップグレード自体は問題なく完了し、

/homeや/optなど、データや実行バイナリを配備していたも影響はありませんでした。

（OSのアップグレードサービスを停止していたので、最初はなかなか上手くいきませんでしたが。。）

とはいえ、新デスクトップ環境cosmicとwaylandでの動作であり、

使い始めると、色々問題がありました。

今後、epoch2と3といったマイルストーンが発表されているので、

使っていくうちに問題は解決するだろうとは期待しています。。。

やはり辛いのは、IMEがデフォルトで入っていないことでしょうか。

fcitxを入れることで、ひとまず日本語の入力は可能となりましたが、

自分はこれまでキーボードの入力ソースを切り替えてやっていたので、どうも慣れない感じです。

ただ、cosmic-terminal等、一部のソフトウェアでは、日本語入力ができずです。。

（パッチを作っている方がいるようですが、日々teminal自身がバージョンアップしているので現状様子見です）

そのほか、アプリケーションのwindow画面の中心位置がずれたり、最大化が遅延したりなど、

描画上の問題もちらほらです。（今まではgnomeのXWindowで問題なし）

ubuntuの26が出てしまっているので、今度は早めに追従してもらいたいですね。

悲観的になるのもなんなので、よいところをいくつか上げておきます。

• 起動が早くなった（気がする）
• cosmic-filesのUIがきれい

あれ、あんまないかも。。

頻繁にアップデートされているので、日々改善されています。

向き合いながら、今後に期待しています。

以上

ebonyrack 1.1.0 をリリースしました。

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

今回は、ローカルDBの変更があるので、プロジェクトをWRITE→READで読み込み直して下さい。

1.0.1〜1.1.0の変更点は以下となります。

（外部キー情報を出力）

私の現場では、外部キーは定義するけど、実際は利用しない、というシーンが多いのですが、

外部キー同士の関係性をたどって、データの不整合を別途検出したいというケースがあり、

JSONファイルとして外部キー情報を出力するようにしました。

↓は、最新のマニュアルのものを出力した例です。※一部修正

[
  {
    "tableName": "m_member",
    "foreignKeys": [
      {
        "constraintName": "m_member_fk_admin_member_id",
        "keyName": "fk_admin_member_id",
        "columnNames": [
          "admin_member_id"
        ],
        "referenceTableName": "m_member",
        "referenceColumnNames": [
          "member_id"
        ],
        "onUpdate": "",
        "onDelete": "",
        "relationship": "0..1 -> 1"
      }
    ]
  },
  {
    "tableName": "t_sale",
    "foreignKeys": [
      {
        "constraintName": "t_sale_fk_product_id",
        "keyName": "fk_product_id",
        "columnNames": [
          "product_id"
        ],
        "referenceTableName": "m_product",
        "referenceColumnNames": [
          "product_id"
        ],
        "onUpdate": "",
        "onDelete": "",
        "relationship": "0..N -> 1"
      },
      {
        "constraintName": "t_sale_fk_sale_member_id",
        "keyName": "fk_sale_member_id",
        "columnNames": [
          "sale_member_id"
        ],
        "referenceTableName": "m_member",
        "referenceColumnNames": [
          "member_id"
        ],
        "onUpdate": "",
        "onDelete": "",
        "relationship": "0..N -> 1"
      }
    ]
  }
]

（パフォーマンス向上）

アウトラインで使うために、秒間2回ワークスペースをキャプチャしているのですが、

キャプチャサイズが大きかったため、サイズを小さくすることで、

パフォーマンス向上を図っています。

（ON UPDATEの修正）

ON UPDATE時に、「CURRENT_TIMESTAMP」以外も入力できるようにしました。

実際は、「CURRENT_TIMESTAMP(3)」とかもできるので、それに対応した修正となっています。

（キーの制約変更）

MariaDBには、ユニークキーのHASHインデックス化という仕様があるのですが、イマイチなのでやめました。

キーの制約については、MySQLに合わせました。

・textは768まで、blobは3072まで

・text/blobは外部キー設定を禁止

（カラムの右クリックによる表示）

最近導入したaliasという機能で、カラムの情報が増えてしまったため、

テーブルオブジェクトのカラム名の部分を右クリックすると、aliasも含めて表示するようにしました。

（ノートの本文を「式」として扱う）

ノートに「式として扱う」というチェックボックスを追加しました。

チェックが入っている場合、DDLとして出力されるようになります。

これで、VIEW/FUNCTION/PROCEDURE/TRIGGERなども、定義できるようにしました。

その他、

• 依存ライブラリの更新
• マニュアルの最新化
• 微調整

なども行っております。

やろうやろうとおもっていたことも大体出来たかなという手応えです。

今後の更新は未定ですが、これから実践で使っていくので、

何かあれば、修正や調整、および機能追加も取り入れていきます。

以上

magentadesk の 0.9.0 をリリースしました。

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

MySQL 8.4の

ERROR 1030 (HY000): Got error 124 - 'Wrong index given to function' from storage engine

のエラーに対応すべく、差分検出クエリーの書き方を大きく変更しました。

この問題は、非常にやっかいでしたが、

書き方変更により、MySQL 8.0系で発生していた重複計上も解消したので、

多少のパフォーマンス向上も見られる形となっています。

この話はUNIONに関係する問題で、色々検証したので、違う記事に詳細を記載しておきます。

さて、magentadeskですが、同じ筐体（同じプロセスが管理する）にある2つのデータベースのテーブルについて、

差分を詳細に検出して、同期するものなのですが、

リモートとの比較をうまくできないかを思案中です。

今のロジックでは、完全外部結合を行い、その差分を利用しているのですが、

リモートとなると、透過的エンジン（Spiderなど）を使って実現したとて、

パフォーマンスが大きく落ちてしまいます。

そのため、レプリケーションをキャプチャして、差分用のテーブルを作っておくなどの対応が必要となります。

ちょっと難しそうですが、やってみようかなとは検討してます。

以上

magentadesk 0.9.0 のリリースでも触れましたが、

MySQLのUNIONに非常に苦しめられました。

具体的には、完全外部結合をする過程の中で、使っているUNIONの箇所で、

ERROR 1030 (HY000): Got error 124 - 'Wrong index given to function' from storage engine

というエラーが発生します。

この原因がどうもMySQL 8.0 から導入されたTempTableエンジンという一時テーブル用のエンジンの不具合のようです。。

そもそも完全外部結合で何をしたいかというと、以下のようなイメージとなります。

要は、同じ構成の2テーブルのレコード差を出す形です。

以下のテーブルとデータを用意してます。

create table base (
  id int not null primary key,
  name text not null
);
insert into base values (1, 'A'),(2, 'B'),(3, 'C');

create table compare (
  id int not null primary key,
  name text not null
);
insert into compare values (1, 'A'),(2, 'BB'),(4, 'D');

外部結合がサポートされているPostgreSQLだと簡単にできます。

(PostgreSQL 18.1)

select
  base.id as base_id, 
  base.name as base_name, 
  compare.id as compare_id, 
  compare.name as compare_name 
from
  base full outer join compare on base.id = compare.id
where
  base.id is null or compare.id is null
  or
  base.id != compare.id or base.name != compare.name
;

 base_id | base_name | compare_id | compare_name 
---------+-----------+------------+-------------
       2 | B         |          2 | BB
       3 | C         |       NULL | NULL
    NULL | NULL      |          4 | D

magentadesk での以前の実装は以下のとおりでした。

これはMariaDBでは問題ありませんでした。当然PostgreSQLでも問題なかったです。

ただし、MySQL 8.0系だと、正しくない結果でした。（結果的にはwhere句を追加して対応）

with
only_base as (
  select * from base
  except
  select * from compare
),
only_compare as (
  select * from compare
  except
  select * from base
),
merge_left as (
  select 
    only_base.id as base_id, 
    only_base.name as base_name, 
    only_compare.id as compare_id, 
    only_compare.name as compare_name
  from only_base left outer join only_compare on only_base.id = only_compare.id
),
merge_right as (
  select 
    only_base.id as base_id, 
    only_base.name as base_name, 
    only_compare.id as compare_id, 
    only_compare.name as compare_name 
  from only_base right outer join only_compare on only_base.id = only_compare.id
),
merge_full as (
  select * from merge_left
  union
  select * from merge_right
)
select
  *
from
  merge_full
;

(MariaDB 12.1)
+---------+-----------+------------+-------------+
| base_id | base_name | compare_id | compare_name |
+---------+-----------+------------+-------------+
|       2 | B         |          2 | BB          |
|       3 | C         |       NULL | NULL        |
|    NULL | NULL      |          4 | D           |
+---------+-----------+------------+-------------+

(PostgreSQL 18.1)
 base_id | base_name | compare_id | compare_name 
---------+-----------+------------+-------------
       3 | C         |       NULL | NULL
       2 | B         |          2 | BB
    NULL | NULL      |          4 | D

(MySQL 8.0.44)
+---------+-----------+------------+-------------+
| base_id | base_name | compare_id | compare_name |
+---------+-----------+------------+-------------+
|       2 | B         |          2 | BB          |
|       3 | C         |       NULL | NULL        |
|       1 | A         |          1 | A           |
|    NULL | NULL      |          4 | D           |
+---------+-----------+------------+-------------+

このクエリーはMySQL 8.4 だと動きません。

そのため、次の形に変更しました。

with
only_base as (
  select id, MD5(IFNULL(name, '')) as row_hash from base
  except
  select id, MD5(IFNULL(name, '')) as row_hash from compare
),
only_compare as (
  select id, MD5(IFNULL(name, '')) as row_hash from compare
  except
  select id, MD5(IFNULL(name, '')) as row_hash from base
),
diff_keys as (
  select id from only_base
  union
  select id from only_compare
),
merge_full as (
  select
    base.id as base_id, 
    base.name as base_name, 
    compare.id as compare_id, 
    compare.name as compare_name 
  from
    diff_keys
    left outer join base on diff_keys.id = base.id
    left outer join compare on diff_keys.id = compare.id
)
select
  *
from
  merge_full
;

ポイントは、

• EXCEPTの比較時はハッシュ化しておく
• UNIONでは主キーのみとする
• 最後の外部結合で情報を取得する

といったところで、ハッシュ化する負荷はあるもののトータルで見れば軽くなった形となります。

これで、MariaDBも、MySQL 8.0および8.4 でも同じ結果を得ることができました。

さすがにわからかなったので、Geminiにも聞きながらやりました。

とはいえ、結構Geminiも間違えていたので、なかなか厄介な問題なのかなと思っています。

magentadesk での以前の実装のクエリーの問題点は、

merge_full as (
  select * from merge_left
  union
  select * from merge_right
)

の部分なのですが、文字列カラム（char/varchar/text）があると、エラーを引き起こすようです。

バイナリは試していないのですが、同じかもしれません。

もちろん、通常のテーブルのUNIONは問題ないのですが、仮想表でのUNIONには気をつけたほうがいいのかな、という所感です。

UNIONだけなの問題なのか、EXCEPTやINTERSECTまで及ぶのかはわからないのですが、

TempTableにはまだ不具合ありそうなので、テンポラリーに落ちるとき（Using temporary）はご注意ください。

以上

ebonyrack 1.0.1 をリリースしました。

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

今回は無事？1.0.0を超えたので、ロゴを修正しつつ、

カラムへのエイリアス設定という機能を追加しました。

これはなんてことない機能なのですが、

クラスファイルを出力時に利用されることを想定しています。

たとえば、データベース上では、intで定義した型であっても、

プログラムではENUMで扱いたいよね、などというときに利用するものです。

エイリアスは3つまで設定できるので、3つのプログラム言語まで対応ってイメージにしてます。

また、カラムの説明なんかも、ノートを使うと見づらくなってしまう場合もあるので、

ここに説明をかくと、DDLにコメントとして表示されるようにしています。

総じて、クラスファイル出力時のお助け機能といったところです。

がんばって体裁は整えていますが、ソースコードもかなり量が多く、

メンテナンスコストもかかるようになってきました。

やっぱり、もうちょっと分割できるような仕組みがよいなーと思い、最近はavalonia.uiを勉強中です。

WPFを知っていることが前提なので、しんどい部分もありますが、

今後記事にできればとは考えています。

以上

2025年8月（もう3ヶ月も前）に、MariaDB 12.0がリリースされました。

STS（正式にはRolling Releaseという）ですが、ついに12系ということで、

ちょっと変更点を見てみたいと思います。

（mariadb 12.0）

https://mariadb.com/docs/release-notes/community-server/release-notes-mariadb-12.0-rolling-releases/what-is-mariadb-120

確か、12.0でmysqlコマンドは完全になくなり、mariadbコマンドになるかなと。

confの設定も、mysqlセクションじゃなくて、mariadbセクションになるのかしら？

ここは見てないのですが、タレの焼き直しが必要そうな匂いですね。

oracleモード関連での強化もなされているようですね。

とはいえ、オプティマイザヒントが入ったり、次のバージョンでcaching_sha2_passwordが入ったりと、

MySQL本家とは離れているようで、機能は似せるようにしている印象です。

個人的には、

explain format=tree ...

が入ってほしいな〜とは期待しています。

また、自分の作っているmagentadeskも0.8.1で、12.0対応済みです。

（magentadesk）

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

最近思うことですが、DBも進化もさることながら、アプリケーションおよび、インフラとかも進化がすごくて、追うのが辛い。。

生成AIは確かにすごいが、アルゴリズムを考えるのがヒトでなくなったとき、ほんとにやばいなーという気がしています。

自分もJetbrainsのAIアシスタントとか使ってますが、書く力がなくなってきているのではないか？と自問自答しています。

とはいえ、JSとかCSSとかについては、知らないことが多いので、AIアシスタントで逆に教えてもらっている側面もあると思うと、なかなか難しいなーとは思いつつ。。

自問自答することが無くなったら、それこそ終わりな気もするので、注意していきたいかなとは思ってます。

以上

ebonyrack 0.9.2 をリリースしました。

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

0.8.5からの主な変更点は以下となります。

（0.8.6）

・マウスドラッグで、ワークスペースを動かせるようにしました。

HTMLの場合と動作を合わせています。

（0.9.0）

・java21に上げました。

・HTML出力時のembed fontをwoff2に変更しました。

・HTML出力時の画像ファイルをPNGからWEBPに変更しました。

（0.9.1）

・テーブルコピー時に、ユニークキー、キー、外部キー、制約をコピーしないようにしました。

※外部キーは元々コピーしてませんでしたが。。

・予約語を見直しました。その結果、oracle mode時の予約語は削除しました。

（0.9.2）

・フォントをMPlus1からmiguに変更しました。

大きな変更はなく、細かな使い勝手の変更です。

fontに関しては、MPlusがとてもきれいで気に入っていたのですが、

全角記号などの外字が表示できないなどがあり、miguフォントに変更しました。

miguフォントはJIS第4水準までカバーしているということなので、

大きな見栄えの変更なく移行できたかなという感じがします。

https://itouhiro.github.io/mixfont-mplus-ipa/migu

HTMLの出力画像ですが、これまでPNGだったのですが、どうしてもサイズが大きくなっていたので、

これをWEBPに変換しました。

・PNGからWEBPの変換

・ttfからwoff2への変換

の2つで、6.3MBのHTMLファイルを、3.5MBまで減らすことができました。

VIEWとか入れようと思っていたのですが、どうしようかなと最近は思い直しています。

NOTEに「コメントとして扱わない」みたいなフラグでも設けて対応するのが安いのかなーとか考えてますが、ちょっと先送りになりそうです。

1機能を足すのに、やるべきことがたくさん発生してしまい、作りがよくないのかなーと思いつつ。。

テスト機能についても、生成AIとか使うほうが簡単じゃない？とか思うようになり、あんまりいらないのかなと。。

というわけで、大きな機能追加はしばらくなさげな感触です。

以上

今月はがんばりました。

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も近づいてきたので（特に意味はないですが）、頑張ろうかと思います。

以上