データベース on hdknr blog

mysqldump エラー 1449: DEFINER が存在しないユーザーを参照している場合の対処法

Thu, 26 Mar 2026 00:00:00 +0000

mysqldump でデータベースをダンプしようとしたら、こんなエラーが出て止まった経験はないでしょうか。

mysqldump: Got error: 1449: The user specified as a definer ('root'@'%') does not exist when using LOCK TABLES

これは MySQL の DEFINER という仕組みに起因するエラーです。ビューやストアドプロシージャの作成時に記録された「定義者（DEFINER）」ユーザーが、現在のサーバー上に存在しない場合に発生します。

なぜ起きるのか

MySQL のビュー、ストアドプロシージャ、トリガー、イベントには DEFINER 属性があります。これはそのオブジェクトを作成した MySQL ユーザーを記録したもので、SQL SECURITY DEFINER（デフォルト）の場合、オブジェクトの実行は DEFINER ユーザーの権限 で行われます。

mysqldump は LOCK TABLES を実行する際、ダンプ対象のビューなどの DEFINER ユーザーを参照します。このとき、DEFINER に設定されたユーザー（例: 'root'@'%'）がサーバー上に存在しなければ、エラー 1449 で処理が中断されます。

よくあるシナリオ:

本番環境から別環境にデータベースをコピーした際、元の環境にいた root@'%' が移行先に存在しない
MySQL のユーザーを整理した際、ビューの DEFINER を更新し忘れた
root@'localhost' しか存在しないのに、ビューが root@'%' で作成されていた

DEFINER が問題のオブジェクトを特定する

まず、どのオブジェクトが問題の原因かを information_schema で確認します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


-- ビュー
SELECT DEFINER, TABLE_SCHEMA, TABLE_NAME
FROM information_schema.VIEWS
WHERE DEFINER LIKE '%root@%';

-- ストアドプロシージャ / ファンクション
SELECT DEFINER, ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE
FROM information_schema.ROUTINES
WHERE DEFINER LIKE '%root@%';

-- イベント
SELECT EVENT_CATALOG, EVENT_SCHEMA, EVENT_NAME, DEFINER
FROM information_schema.EVENTS
WHERE DEFINER LIKE '%root@%';

-- トリガー
SELECT TRIGGER_SCHEMA, TRIGGER_NAME, DEFINER
FROM information_schema.TRIGGERS
WHERE DEFINER LIKE '%root@%';

多くの場合、ビューが原因です。該当するオブジェクトが見つかったら、その定義を確認しましょう。

急成長でぶつかったMySQLの罠とその向き合い方 - 7つの実践的な教訓

Fri, 20 Mar 2026 00:00:00 +0000

Timee のプラットフォームエンジニアリングチームの徳富博氏による発表「急成長でぶつかったMySQLの罠とその向き合い方」から、Aurora MySQL 運用で遭遇した 7 つの重要な課題とその対策をまとめます。

サービスの急成長に伴い、小規模では問題にならなかった MySQL の挙動が本番環境で深刻な障害を引き起こすことがあります。この発表では、実際の運用経験に基づいた具体的な対策が共有されています。

1. DDL 実行の落とし穴

DDL（Data Definition Language: テーブル定義の変更操作）には「Online DDL」という仕組みがありますが、DDL 実行中もテーブルへのアクセスがブロックされないわけではありません。実際にはメタデータロック（MDL）が必ず発生します。

Aurora のレプリカでは DDL 実行時にコネクションが切断されるため、リトライロジックが必須
外部キー制約を追加する際は foreign_key_checks = 0 を設定すると、COPY アルゴリズムではなく INPLACE アルゴリズム（テーブルの再構築を伴わない方式）が使われ、影響を最小化できる

2. MDL ベースのデッドロック

MDL デッドロックは SHOW ENGINE INNODB STATUS に表示されないため、標準的な監視では検知できません。

外部キーが存在すると、DROP/ALTER 操作時に親テーブルに対して広範な MDL が取得される
対策: DDL 操作の前に外部キー制約を削除する

3. レプリカがライターに影響を与える問題

Aurora ではレプリカとライターがストレージボリュームを共有しています。レプリカ上の長時間クエリが undo ログのクリーンアップを妨げ、ライターのパフォーマンスに影響します。

MySQL のデフォルトの分離レベルは REPEATABLE READ だが、分析用クエリには READ COMMITTED を使用することで、リードビューの保持期間を短縮し undo ログの蓄積を抑えられる

4. 同時リクエストによるデッドロック

高トラフィック環境では、確率的に発生する競合が確実に障害を引き起こすようになります。

ギャップロックパターン

ギャップロック（インデックスレコード間の隙間に対するロック）同士は競合しませんが、複数のトランザクションが同時に INSERT を実行すると循環待ちが発生します。

DuckDB・Apache Arrow・Parquetの関係を整理する：列指向エコシステムの全体像

Thu, 19 Mar 2026 00:00:00 +0000

DuckDB は「SQLite の分析版」とも呼ばれるインプロセス OLAP データベースです。Apache Arrow、Apache Parquet と同じ列指向の思想を持ちますが、三者の役割はそれぞれ異なります。この記事では DuckDB のアーキテクチャ、Arrow・Parquet との関係、そして従来の行指向 DB との違いを整理します。

Parquet・Arrow・DuckDB の位置付け

	Parquet	Arrow	DuckDB
何か	ディスク上の列指向ファイル形式	インメモリ列指向データフォーマット（仕様+ライブラリ）	SQL データベースエンジン
レイヤー	ストレージ（ディスク）	データ交換（メモリ）	クエリ実行（エンジン）
目的	効率的な永続化・圧縮	アプリケーション間のゼロコピーデータ交換	SQL クエリの実行・最適化

三者は列指向エコシステムの異なるレイヤーを担っており、補完関係にあります。

[ディスク] Parquet ファイル（列指向・圧縮済み）
↓ 読み込み（必要な列だけ）
[メモリ] Arrow フォーマット（列指向・ゼロコピー）
↓ クエリ実行
[エンジン] DuckDB（ベクトル化 SQL 実行）

Parquet は「データの保存形式」、Arrow は「メモリ上のデータの並べ方の規格」、DuckDB は「SQL を実行するエンジン」です。三者とも列指向という共通思想を持つため、組み合わせるとデータ変換のオーバーヘッドがほぼ発生しません。

DuckDB の高速性を支える3つの柱

1. 列指向ストレージ

行単位ではなく列単位でデータを格納します。分析クエリ（SUM, AVG, GROUP BY など）で必要な列だけを読み込むため、I/O が効率的です。

2. ベクトル化実行エンジン

1行ずつではなく、列のチャンク（ベクトル）単位で処理します。これにより CPU キャッシュのヒット率が上がり、SIMD 命令も活用できます。

3. 自動並列化

マルチコアを自動的に活用し、クエリを並列実行します。ユーザー側で並列化の設定を意識する必要はありません。

redis-py の Lock をサブクラス化してフェンシングトークンを実装する

Tue, 17 Mar 2026 00:00:00 +0000

redis-py の Lock クラスは UUID ベースのトークンでロックの所有権を管理するが、フェンシングトークン（単調増加する数値）は提供しない。しかし、Lock クラスは do_acquire や Lua スクリプトをオーバーライドできる設計になっており、サブクラス化でフェンシングトークンを追加できる。

本記事では、redis-py の Lock を拡張してフェンシングトークンを発行する FencedLock クラスの実装例を紹介する。

前提知識：Redis の Lua スクリプティング

Redis はバージョン 2.6 から Lua スクリプトの実行機能を内蔵している。EVAL コマンドで Lua スクリプトを Redis サーバー上で直接実行でき、複数の Redis コマンドをアトミック（不可分）に実行できる。

なぜ Lua スクリプトが必要か

通常、Redis コマンドは1つずつ実行される。例えば「キーが存在しなければセットし、同時にカウンターをインクリメントする」という処理を2つのコマンドで行うと、その間に他のクライアントが割り込む可能性がある：

クライアント A: SET mykey value NX → 成功
← クライアント B が割り込む余地
クライアント A: INCR counter → インクリメント

Lua スクリプトを使えば、この2つの操作を1回のアトミックな呼び出しにまとめられる：

1
2
3
4
5
6


-- Redis サーバー上で実行される（他のコマンドは割り込めない）
local ok = redis.call('SET', KEYS[1], ARGV[1], 'NX')
if ok then
 return redis.call('INCR', KEYS[2])
end
return nil

Redis CLI での実行例

1
2


# EVAL "スクリプト" キーの数 キー1 キー2 ... 引数1 引数2 ...
redis-cli EVAL "return redis.call('SET', KEYS[1], ARGV[1])" 1 mykey myvalue

redis-py での実行例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


import redis
r = redis.Redis()

# 方法1: eval で直接実行
r.eval("return redis.call('SET', KEYS[1], ARGV[1])", 1, "mykey", "myvalue")

# 方法2: register_script で事前登録（推奨）
# サーバー側に SHA1 でキャッシュされ、2回目以降はスクリプト本文の転送が不要
script = r.register_script("return redis.call('GET', KEYS[1])")
result = script(keys=["mykey"])

セキュリティ上の注意

Lua スクリプトのパラメータは KEYS[] と ARGV[] で渡される。SQL のプリペアドステートメントと同様に、パラメータが文字列としてスクリプトに展開されることはないため、パラメータ経由でのインジェクションはできない。ただし、ユーザー入力でスクリプト文字列自体を動的に組み立てると危険なので、スクリプトは固定文字列として定義すること。

Redisを「共有状態」として使うアンチパターン：キー設計の落とし穴

Mon, 09 Mar 2026 00:00:00 +0000

Redis はキャッシュとして非常に優秀なツールだが、複数のチームやサービスが**共有状態（shared state）**として Redis を使い始めると、設計上の問題が発生しやすくなる。

キャッシュと共有状態の違い

Redis をキャッシュとして使う場合、データは一時的なものであり、いつ消えても問題ない。元データは RDB などに存在し、キャッシュミス時に再構築できる。

一方、共有状態として使う場合は話が変わる。複数のサービスが同じ Redis キーを読み書きし、そのデータが「正」として扱われる。RDB のようなスキーマや制約がないため、以下の問題が起きやすい。

暗黙の契約に依存したデータ構造

RDB であればスキーマによってデータ構造が明示的に定義される。カラム名、型、制約、外部キーなどが設計書の役割を果たす。

Redis にはそのような仕組みがない。キーの命名規則やデータ形式は開発者間の「暗黙の契約」に依存する。チームが増えると、以下のような問題が顕在化する：

キーの命名が衝突する — 異なるチームが同じプレフィックスを使ってしまう
データ形式の不一致 — あるサービスは JSON、別のサービスは MessagePack で書き込む
バージョン管理の欠如 — データ構造を変更しても、読み取り側が追従できない

「削除できないキー」問題

最も厄介な問題の一つが、誰が所有しているのか分からないキーが残り続けることだ。

本番環境で以下のような状況が発生する：

# このキーは誰が作った？いつ expire する？削除していい？
GET user:session:abc123:metadata

作成したサービスがすでに廃止されている
TTL が設定されていないため、永遠に残る
他のサービスが依存している可能性があり、安易に削除できない

キーを「パブリック API」として扱う

この問題に対する実践的なアプローチとして、Redis キーをパブリック API のように扱うという考え方がある：

バージョニング — キー名にバージョンを含める（例: v2:user:session:{id}）
ドキュメント化 — どのキーがどのサービスによって管理されているかを明文化する
オーナーの明確化 — 各キーに責任を持つチーム・サービスを割り当てる
TTL の必須化 — 共有キーには必ず TTL を設定し、期限切れを明示する

補足：分散ロック基盤としての Redis

Redis を共有状態として使うもう一つの典型例が、トランザクション境界をまたぐ分散ロックだ。SET key value NX PX timeout を使ったロックや、Redlock アルゴリズムは広く利用されているが、ここにも落とし穴がある。

Software Design 2026年4月号の注目特集：PostgreSQL 18 高速化と MCP サーバー開発

Mon, 09 Mar 2026 00:00:00 +0000

技術評論社の Software Design 2026年4月号（2026年3月18日発売）の特集内容を紹介します。今号は PostgreSQL 18 のパフォーマンス最適化と、MCP サーバー開発という2つの注目特集が組まれています。

第1特集：PostgreSQL 18 に学ぶデータベース高速化機能

「アーキテクチャから見えてくる処理性能向上のヒント」と題した第1特集では、PostgreSQL 18 の新機能を軸にデータベース高速化のテクニックが解説されています。

章構成

第1章 データ処理メカニズムと高速化（三谷篤）
第2章 トランザクションとバックアップ（三谷篤）
第3章 クエリ最適化とオプティマイザー（篠田典良）
第4章 インデックス検索技法（篠田典良）
第5章 並列処理と JIT（寺内大輝）
第6章 PostgreSQL 互換クラウド DB 比較（小山哲志）
第7章 PostgreSQL 18 の新機能（寺内大輝）

PostgreSQL のデータ処理メカニズムから始まり、クエリ最適化、インデックス活用、並列処理・JIT コンパイルまで、パフォーマンスチューニングの全体像をカバーする構成です。第6章では PostgreSQL 互換のクラウドデータベース（Amazon Aurora、AlloyDB など）の比較もあり、実務で選定する際の参考になります。

第2特集：MCP サーバー開発成功の秘訣

「事業戦略・品質・開発効率をふまえたアプローチ」と題した第2特集では、AI エージェントのツール連携で注目される MCP（Model Context Protocol）サーバーの開発について、実践的なアプローチが紹介されています。

章構成

第1章 MCP 設計ガイド（川崎庸市）
第2章 駅すぱあと API での事例（橋本あゆみ、平川瑞樹）
第3章 Sansan での事例（川瀬圭亮）

MCP は Anthropic が提唱した AI モデルと外部ツールを接続するためのオープンプロトコルで、Claude Code をはじめ多くの AI ツールで採用が進んでいます。本特集では設計の基本方針に加え、駅すぱあと API や Sansan といった実サービスでの MCP サーバー構築事例が紹介されており、自社サービスに MCP を導入する際の具体的な指針が得られます。

RuView × Wi-Fi電波で壁越し人体検知 — $48で心拍・姿勢を丸裸にする技術の実態

Fri, 06 Mar 2026 00:00:00 +0000

RuView × Wi-Fi電波で壁越し人体検知 — $48で心拍・姿勢を丸裸にする技術の実態

TL;DR: カメラなし・$48のESP32だけで壁の向こうの人間の心拍・呼吸・骨格17点を検知できるとするオープンソースプロジェクト「RuView」がSNSで話題に。原理はCMU発の査読済み研究に基づく実在技術だが、「28.5kスター」の裏には再現性への疑義とCSIハードウェアの壁がある。煽りと科学を分離して整理する。

話題の発端

@kosuke_agos氏のポスト（2026年3月5日、閲覧6.4万・ブックマーク456）が日本語圏で拡散。「市販Wi-Fiルーターだけで壁の向こう側の人間の心拍数や姿勢を完全に特定」「わずか48ドルで構築」という衝撃的な内容が注目を集めた。

https://x.com/kosuke_agos/status/2029392193325285521

RuView とは何か

RuView（旧wifi-densepose）は、Wi-Fi信号のCSI（Channel State Information）を解析して、カメラなしで人体の姿勢推定・バイタルサイン検知を行うオープンソースプロジェクト。

GitHub: https://github.com/ruvnet/RuView
スター: 28.5k / フォーク: 3.7k
ライセンス: MIT
実装言語: Rust（Python比810倍の処理速度を主張）

主張されている性能

機能	スペック
骨格トラッキング	17箇所のキーポイント
呼吸検知	6-30 BPM
心拍検知	40-120 BPM
処理速度	54,000 fps（Rust実装）
壁越し検知距離	最大5m
AIモデルサイズ	55KB（エッジ実行可能）
ハードウェアコスト	〜$48（ESP32-S3 × 4-6台）

科学的な背景 — CMU「DensePose From WiFi」

RuView の理論的基盤は、カーネギーメロン大学（CMU）ロボティクス研究所が2022年に発表した査読済み論文「DensePose From WiFi」（arXiv: 2301.00250）。

論文の核心

Wi-Fiの**CSI（チャネル状態情報）**は、空間内の物体・人体による電波の反射・回折・散乱を数値化したもの
CSI信号を画像的な2D特徴マップに変換するエンコーダ・デコーダネットワークを構築
修正版DensePose-RCNNで、2D特徴から人体表面のUV座標を推定
複数人の同時検知が可能で、カメラベースのアプローチに匹敵する性能を達成

この研究は実在し、査読を通過しており、Wi-Fi CSI による人体検知という原理自体は「嘘」ではない。

CSI の仕組み（簡略版）

Wi-Fi ルーター → 電波送信（OFDM: 52サブキャリア）
↓
人体が電波を反射・吸収・散乱
↓
ESP32 受信 → 各サブキャリアの振幅・位相変化を記録（= CSI）
↓
AI が CSI パターンから人体の姿勢・バイタルを推定

呼吸は胸部の周期的な膨張・収縮（6-30回/分）、心拍は胸壁の微小振動（40-120回/分）として、CSIのFFT（高速フーリエ変換）解析で分離・抽出される。

Redis Pub/Sub から Streams への移行で帯域 99% 削減 --- 同時接続 30 万超チャットの実践記録

Mon, 02 Mar 2026 00:00:00 +0000

Redis Pub/Sub から Streams への移行で帯域 99% 削減 — 同時接続 30 万超チャットの実践記録

Keisuke Nishitani 氏(@Keisuke69)のポストで、LY Corp（旧 LINE）の技術ブログ記事が紹介されていました。同時接続数 30 万超の LINE 公式アカウント（OA）チャットが、メッセージ配信基盤を Redis Cluster の Pub/Sub から Redis Streams へ移行した事例です。ピーク時 1.5 Gbps だったノードあたりの帯域が 11 Mbps まで削減されたという結果は、大規模リアルタイムシステムを運用するエンジニアにとって示唆に富む内容です。

同時接続数30万超のチャットサービスのメッセージ配信基盤をRedis Pub/SubからRedis Streamsにした話 — @Keisuke69

背景 — Redis Cluster Pub/Sub のスケール限界

LINE 公式アカウントのチャット機能（OA チャット）は、ユーザーから送られたメッセージを OA オーナーにリアルタイムで配信する仕組みを持っています。この配信基盤として Redis Cluster の Pub/Sub を使用していました。

問題は Redis Cluster における Pub/Sub の仕様にあります。あるシャードに publish されたメッセージは、クラスター内の全シャードにブロードキャストされます。24 シャード構成であれば、1 メッセージが残り 23 シャードに伝搬するため、アウトバウンドトラフィックはインバウンドの 23 倍になります。

指標	値
クラスター構成	24 シャード / 48 ノード
ノードあたり帯域（平常時）	500 Mbps
ノードあたり帯域（ピーク時）	1.5 Gbps

シャードを増やせばクラスター性能は上がりますが、同時にブロードキャストのトラフィックも増えるというジレンマがあり、スケールアウトが頭打ちになっていました。

PolarDB

Wed, 31 Jul 2024 00:00:00 +0000

PolarDB for PostgreSQL

PolarDB for PostgreSQL（以下、PolarDB）は、Alibaba Cloud が独自に開発したクラウドネイティブなデータベースサービスです。
このサービスは、PostgreSQL と 100%互換性があり、共有ストレージベースのアーキテクチャを採用しています。
これにより、計算とストレージが分離され、柔軟なスケーラビリティ、ミリ秒レベルの遅延、HTAP（Hybrid Transactional/Analytical Processing）機能を提供します ¹²。

主な特徴は以下の通りです：

柔軟なスケーラビリティ：ビジネス要件に応じて、計算クラスターやストレージクラスターをスケールアウトできます。
ミリ秒レベルの遅延：WAL（Write-Ahead Logging）ログが共有ストレージに保存され、メタデータのみがレプリケートされます。
HTAP 機能：OLTP（オンライントランザクション処理）と OLAP（オンライン分析処理）の両方をサポートするためのアーキテクチャを持っています ¹²³。

他に知りたいことがあれば教えてくださいね。

ソース: Copilot との会話、 2024/7/31 (1) GitHub - ApsaraDB/PolarDB-for-PostgreSQL: A cloud-native …. https://github.com/ApsaraDB/PolarDB-for-PostgreSQL. (2) PolarDB for PostgreSQL - Gitee. https://gitee.com/polardb/PolarDB-for-PostgreSQL. (3) PolarDB云原生数据库自研数据库_数据库-阿里云. https://polardbpg.com/. (4) PolarDB: 阿里云开源云原生数据库 PolarDB - Gitee. https://gitee.com/polardb.

記事

PolarDB for PostgreSQL 14 で pgvector と LangChain を使ってベクトル検索してみる

Redis キーの作成時刻

Mon, 06 Nov 2023 00:00:00 +0000

Redis キーの登録日時

Redis でキーを登録した時刻を取得するには、残念ながら直接的な方法はありません。Redis はキーの作成日時や更新日時を保存していないからです ¹。ただし、いくつかの回避策があります。

キーを登録するときに、別のキーにタイムスタンプを保存する。例えば、SET foo barとするときに、SET foo:timestamp 1636106362というように、キーの名前に:timestampを付けて現在の UNIX 時間を値として保存する。この方法では、キーの数が増えるとメモリの消費量も増えることに注意が必要です。
キーの値にタイムスタンプを含める。例えば、SET foo bar:1636106362というように、値の末尾に:と現在の UNIX 時間を付ける。この方法では、値の取得や操作において、タイムスタンプを除去する必要があることに注意が必要です。
キーに有効期限を設定する。例えば、EXPIRE foo 3600とすると、キーfooは 1 時間後に削除される。このとき、TTL fooとすると、キーの残りの有効期限が秒単位で返される。この値から、キーの登録時刻を逆算することができる。この方法では、キーが削除されると時刻を取得できなくなることに注意が必要です。

以上の方法のいずれも完璧ではありませんが、Redis でキーの登録時刻を取得するための可能な解決策として参考にしてください。

¹: Redis でキーの作成日時や更新日時を取得する方法はありますか？ - スタック・オーバーフロー.

ソース: Bing との会話 2023/11/6 (1) redis-cli でよく使うコマンド 20 選 #Redis - Qiita. https://qiita.com/hatsu/items/a52817364160e0b6bb60. (2) redis-cli でよく使うコマンド 20 選 #Redis - Qiita. https://qiita.com/hatsu/items/a52817364160e0b6bb60. (3) 全データ型対応の操作 — redis 2.0.3 documentation - shibu.jp. http://redis.shibu.jp/commandreference/alldata.html. (4) 【2022 年最新版】【Redis メモ・3】キーに有効期限を付与し …. https://www.servernote.net/article.cgi?id=redis-note-3. (5) セッション管理として Redis を使用する - RAKUS Developers Blog …. https://tech-blog.rakus.co.jp/entry/2017/10/17/111828. (6) ja.wikipedia.org. https://ja.wikipedia.org/wiki/Redis.

DRF: DataFrame を使って CSV エクスポート

Tue, 22 Aug 2023 00:00:00 +0000

DRF: DataFrame を使って CSV エクスポート

CSV レンダラー

1
2
3
4
5
6
7


def dataframe_to_csv_stream(df, encoding=None, **kwargs):
 buffer = BytesIO()
 df.to_csv(buffer, **kwargs)
 buffer.seek(0)
 if encoding:
 return BytesIO(buffer.read().decode("utf8").encode(encoding))
 return buffer

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


class DataFrameCSVRenderer(BaseRenderer):
 media_type = "text/csv"
 format = "csv"

 def render(self, data, media_type=None, renderer_context=None, writer_opts=None):
 renderer_context = renderer_context or {}
 if not isinstance(data, pd.DataFrame):
 data = pd.DataFrame(data)
 stream = dataframe_to_csv_stream(data, index=False)
 return stream.read().decode("utf-8-sig")

DataFrame を返すリストシリアライザ

1
2
3
4
5
6
7


class DataFrameSerializer(serializers.ListSerializer):
 @property
 def data(self):
 ret = super().data
 ser = ret.serializer.child
 columns = dict((name, field.label) for name, field in ser.fields.items())
 return pd.DataFrame(ret).rename(columns=columns)

エクスポートするシリアライザを生成するメタクラス

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25



class ExpporSerializerMetaclass(serializers.SerializerMetaclass):
 EXPORT_META = {}
 FIELD_CLASS_DEFAULTS = {}

 @classmethod
 def create_fields(cls):
 def _create_field(item):
 label, name, klass = item
 defaults = cls.FIELD_CLASS_DEFAULTS[klass]
 return (name, getattr(serializers, klass)(label=label, **defaults))

 return dict(map(_create_field, cls.EXPORT_META))

 @classmethod
 def annotate(cls, queryset):
 raise NotImplementedError()

 def __new__(cls, name, bases, attrs, **kwargs):
 attrs["Meta"].fields = [i[1] for i in cls.EXPORT_META] # CSVで返答するカラム
 attrs["Meta"].list_serializer_class = DataFrameSerializer # リストシリアライザ
 attrs.update(**cls.create_fields())
 attrs["annotate"] = cls.annotate # クエリセットをアノテートさせるクラスメソッド 

 return super().__new__(cls, name, bases, attrs, **kwargs)

実際のメタクラス

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


class IncomeExpporSerializerMetaclass(ExpporSerializerMetaclass):
 # (ラベル, フィールド名, フィールドクラス名)
 EXPORT_META = [
 ("会社コード", "order__company_code", "CharField"),
 ....
 ]

 # フィールドクラスのデフォルト値
 FIELD_CLASS_DEFAULTS = dict(
 CharField=dict(read_only=True),
 DecimalField=dict(max_digits=12, decimal_places=1, read_only=True),
 )

 @classmethod
 def annotate(cls, queryset):
 """ クエリセットを適切にアノテートする"""
 def _ann(item):
 label, name, klass = item
 if name.startswith("order__"):
 # リレーション
 return (name, F(name))
 if name.startswith("meme__"):
 # 固定値
 return (name, Value(""))
 # その他はモデルフィールドなのでアノテートしない
 return (None, None)

 ann = dict(filter(lambda i: i[1] is not None, map(_ann, cls.EXPORT_META)))
 return queryset.annotate(**ann)

実際のシリアライザ

1
2
3


class IncomeExportSerializer(serializers.ModelSerializer, metaclass=IncomeExpporSerializerMetaclass):
 class Meta:
 model = models.Income

API 本体(ビューセット)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


class IncomeViewSet(VS.BaseModelViewSet):

 serializer_class = serializers.IncomeSerializer
 queryset = models.Income.objects.all()
 pagination_class = paginations.Pagination

 renderer_classes = tuple(api_settings.DEFAULT_RENDERER_CLASSES) + (DataFrameCSVRenderer,)

 def get_serializer_class(self):
 """ export アクションでシリアライザを切り替える """
 res = {
 "export": serializers.IncomeExportSerializer,
 }.get(self.action, super().get_serializer_class())
 return res

 def get_queryset(self):
 """ export アクションの場合、必要なアノテーションを行う """
 qs = super().get_queryset()
 if self.action == "export":
 qs = serializers.IncomeExportSerializer.annotate(qs).filter(level=0)
 return qs
 return qs

 @decorators.action(methods=["get"], detail=False)
 def export(self, request, pk=None):
 ## リスト処理を行うと シリアライザとレンダラで勝手にCSVを返答する(Accept: text/csvの時)
 return self.list(request)

MySQL BULK INSERT

Tue, 15 Aug 2023 00:00:00 +0000

MySQL バルクインサート

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


@main.command()
@click.argument("source_file")
@click.option("--encoding", "-e", default="cp932")
@click.pass_context
def data_import(ctx, source_file, encoding):
 """ import TSV file """

 opt = get_model()._meta
 fields = ",".join([f.name for f in opt.fields if f.name not in ["id"]])
 SQL = f"""
 LOAD DATA LOCAL INFILE '{source_file}' INTO TABLE {opt.db_table}
 CHARACTER SET {encoding}
 FIELDS TERMINATED BY '\t' ({fields}) ;
 """

 with connection.cursor() as cursor:
 cursor.execute(SQL)
 print(cursor.fetchall())

重複時に UPDATE する(REPLACE):

MySQL only_full_group_by

Fri, 30 Jun 2023 00:00:00 +0000

`only_full_group_by`

エラー:

1
2
3
4
5
6


OperationalError: (
 1055,
 "Expression #1 of SELECT list is not in GROUP BY clause
 and contains nonaggregated column 'server.sales_sales.sales_status'
 which is not functionally dependent on columns in GROUP BY clause;
 this is incompatible with sql_mode=only_full_group_by")

対処: sql_mod に traditional を指定する

MySQL 半角カナ検索

Wed, 31 May 2023 00:00:00 +0000

utf8mb4_0900_ai_ci

「utf8mb4_0900_ai_ci」という照合順序は、MySQL 8.0 から標準になった照合順序で、Unicode 9.0 の文字セットをサポートしています。¹

この照合順序は、文字列の比較において、アクセントや大小文字を区別せずに比較することができます。¹

また、日本語のようなマルチバイト文字を含む文字列を扱う場合にも適しています。¹¹: MySQL 8.0 の照合順序で標準になった「utf8mb4_0900_ai_ci」とは - Qiita

ソース: Bing との会話 2023/5/31

(1) MySQL 8.0 の照合順序で標準になった「utf8mb4_0900_ai_ci …. https://qiita.com/seltzer/items/8b5d8a61591e72715d5b.
(2) MySQL :: MySQL 8.0 リファレンスマニュアル :: 10.5 …. https://dev.mysql.com/doc/refman/8.0/ja/charset-applications.html.
(3) MySQL :: MySQL 8.0 リファレンスマニュアル :: 10.4 接続文字 …. https://dev.mysql.com/doc/refman/8.0/ja/charset-connection.html.

半角カナの濁点ありは照合順序の設定では解決できない

utf8mb4_0900_ai_ci での検索:

where	結果
`ベル`	`ヘル`, `ベル`, `ﾍﾙ` (つまり、 `ﾍﾞﾙ` は一致しない)
`ヘル`	`ヘル`, `ベル`, `ﾍﾙ` (つまり、 `ﾍﾞﾙ` は一致しない)
`ﾍﾙ`	`ヘル`, `ベル`, `ﾍﾙ` (つまり、 `ﾍﾞﾙ` は一致しない)
`ﾍﾞﾙ`	`ﾍﾞﾙ` (のみ)

django-filter: method フィルターで対応

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


from functools import reduce
from operator import or_
import django_filters as DF
import jaconv


def filter_icontains_mix(queryset, name, value):
 """全角半角を区別しないで検索(濁点対応)"""

 if not value:
 return queryset

 values = set([jaconv.h2z(value), jaconv.z2h(value)])

 def _query(v):
 return Q(**{f"{name}__icontains": v})

 query = reduce(or_, map(_query, values))
 return queryset.filter(query)


class OrderFilter(DF.FilterSet):
 ...
 customer_name__contains = DF.CharFilter(
 field_name="customer_name", lookup_expr="icontains", method=filter_icontains_mix
 )
 ...

MySQL: ERROR 1553 (HY000): Cannot drop index 'uniq_profit': needed in a foreign key constraint

Wed, 26 Apr 2023 00:00:00 +0000

MySQL: ERROR 1553 (HY000): Cannot drop index ‘uniq_profit’: needed in a foreign key constraint

MySQL で一意制約が削除できない

1
2
3


 UNIQUE KEY `uniq_profit` (`sales_id`,`accounting_status`),
 CONSTRAINT `costs_profit_sales_id_d56dec15_fk_sales_sales_id` FOREIGN KEY (`sales_id`) REFERENCES `sales_sales` (`id`),
 CONSTRAINT `costs_profit_chk_1` CHECK ((`fiscal_year` >= 0))

1
2


ALTER TABLE `costs_profit` DROP FOREIGN KEY `costs_profit_sales_id_d56dec15_fk_sales_sales_id`, DROP INDEX `uniq_profit`;
ALTER TABLE `costs_profit` ADD CONSTRAINT `costs_profit_sales_id_d56dec15_fk_sales_sales_id` FOREIGN KEY (`sales_id`) REFERENCES `sales_sales` (`id`);

実行:

1
2
3
4
5
6
7


mysql> ALTER TABLE `costs_profit` DROP FOREIGN KEY `costs_profit_sales_id_d56dec15_fk_sales_sales_id`, DROP INDEX `uniq_profit`;
Query OK, 0 rows affected (0.20 sec)
Records: 0 Duplicates: 0 Warnings: 0

mysql> ALTER TABLE `costs_profit` ADD CONSTRAINT `costs_profit_sales_id_d56dec15_fk_sales_sales_id` FOREIGN KEY (`sales_id`) REFERENCES `sales_sales` (`id`);
Query OK, 16 rows affected (0.17 sec)
Records: 16 Duplicates: 0 Warnings: 0

Django Migration の失敗

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


from django.db import migrations, models


class Migration(migrations.Migration):

 dependencies = [
 ('partners', '0003_auto_20230426_0908'),
 ]

 operations = [
 migrations.RemoveConstraint(
 model_name='partneruserrole',
 name='uniq_partneruserrole',
 ),
 migrations.AddConstraint(
 model_name='partneruserrole',
 constraint=models.UniqueConstraint(fields=('partner', 'partneruser', 'permission'), name='uniq_partneruserrole'),
 ),
 ]

制約検索

1
2
3
4
5
6
7
8
9


SELECT DISTINCT A.CONSTRAINT_NAME, A.TABLE_NAME, A.COLUMN_NAME, B.CONSTRAINT_NAME
FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE as A
JOIN INFORMATION_SCHEMA.KEY_COLUMN_USAGE as B
ON A.TABLE_NAME = B.TABLE_NAME
WHERE
 A.TABLE_NAME = 'partners_partneruserrole'
 AND B.CONSTRAINT_NAME like 'uniq_%'
 AND A.CONSTRAINT_NAME not like 'uniq_%'
 AND A.CONSTRAINT_NAME != 'PRIMARY';

+-----------------------------------------------------------+--------------------------+----------------+----------------------+
| CONSTRAINT_NAME | TABLE_NAME | COLUMN_NAME | CONSTRAINT_NAME |
+-----------------------------------------------------------+--------------------------+----------------+----------------------+
| partners_partneruser_partneruser_id_d59f67cc_fk_partners_ | partners_partneruserrole | partneruser_id | uniq_partneruserrole |
| partners_partneruser_partner_id_852ab185_fk_partners_ | partners_partneruserrole | partner_id | uniq_partneruserrole |
| partners_partneruser_permission_id_031e3996_fk_auth_perm | partners_partneruserrole | permission_id | uniq_partneruserrole |
+-----------------------------------------------------------+--------------------------+----------------+----------------------+

再設定

1
2
3
4
5
6
7


ALTER TABLE `partners_partneruserrole` DROP FOREIGN KEY `partners_partneruser_partneruser_id_d59f67cc_fk_partners_`;
ALTER TABLE `partners_partneruserrole` DROP FOREIGN KEY `partners_partneruser_partner_id_852ab185_fk_partners_`;
ALTER TABLE `partners_partneruserrole` DROP FOREIGN KEY `partners_partneruser_partner_id_852ab185_fk_partners_`, DROP INDEX `uniq_profit`;

ALTER TABLE `partners_partneruserrole` ADD CONSTRAINT `partners_partneruser_partneruser_id_d59f67cc_fk_partners_` FOREIGN KEY (`partneruser_id`) REFERENCES `partners_partneruser` (`id`);
ALTER TABLE `partners_partneruserrole` ADD CONSTRAINT `partners_partneruser_partner_id_852ab185_fk_partners_` FOREIGN KEY (`partner_id`) REFERENCES `partners_partner` (`id`);
ALTER TABLE `partners_partneruserrole` ADD CONSTRAINT `partners_partneruser_permission_id_031e3996_fk_auth_perm` FOREIGN KEY (`permission_id`) REFERENCES `auth_permission` (`user_ptr_id`);

最終スキーマ

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


DROP TABLE IF EXISTS `partners_partneruserrole`;
CREATE TABLE `partners_partneruserrole` (
 `id` bigint NOT NULL AUTO_INCREMENT,
 ....
 PRIMARY KEY (`id`),
 UNIQUE KEY `uniq_partneruserrole` (`partner_id`,`partneruser_id`,`permission_id`),
 KEY `partners_partneruser_partneruser_id_d59f67cc_fk_partners_` (`partneruser_id`),
 KEY `partners_partneruser_permission_id_031e3996_fk_auth_perm` (`permission_id`),
 CONSTRAINT `partners_partneruser_partner_id_852ab185_fk_partners_` FOREIGN KEY (`partner_id`) REFERENCES `partners_partner` (`id`),
 CONSTRAINT `partners_partneruser_partneruser_id_d59f67cc_fk_partners_` FOREIGN KEY (`partneruser_id`) REFERENCES `partners_partneruser` (`user_ptr_id`),
 CONSTRAINT `partners_partneruser_permission_id_031e3996_fk_auth_perm` FOREIGN KEY (`permission_id`) REFERENCES `auth_permission` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

MySQL: ERROR 3780 (HY000) at line 1406622: Referencing column 'os_branch_id' and referenced column 'id' in foreign key constraint '***' are incompatible.

Thu, 06 Apr 2023 00:00:00 +0000

`ERROR 3780 (HY000) at line 1406622: Referencing column 'os_branch_id' and referenced column 'id' in foreign key constraint '***' are incompatible.`

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


CREATE TABLE `gas_bombehouse` (
 `id` int NOT NULL AUTO_INCREMENT,
 `code` varchar(50) NOT NULL,
 ....
 `os_branch_id` bigint DEFAULT NULL,
 PRIMARY KEY (`id`),
 UNIQUE KEY `code` (`code`),
 KEY `gas_bombehouse_os_branch_id_d35d17d3_fk_outsource` (`os_branch_id`),
 CONSTRAINT `gas_bombehouse_os_branch_id_d35d17d3_fk` FOREIGN KEY (`os_branch_id`) REFERENCES `outsources_outsourcebranch` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8mb3;
/*!40101 SET character_set_client = @saved_cs_client */;

1
2
3
4
5
6
7



CREATE TABLE `outsources_outsourcebranch` (
 `id` bigint NOT NULL AUTO_INCREMENT,
 ...
 PRIMARY KEY (`id`),
) ENGINE=InnoDB AUTO_INCREMENT=9751 DEFAULT CHARSET=utf8mb3;
/*!40101 SET character_set_client = @saved_cs_client */;

原因

リモートの mysqldump をローカルにそのまま取り込もうとしていた
古いスキーマが残っていて、そのidがint であったため。
DROP TABLE IF EXISTS table CREATE TABLE table が実行されるまで、古いスキーマが残っている、ということ。

1
2
3
4
5


DROP TABLE IF EXISTS `outsources_outsourcebranch`;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!50503 SET character_set_client = utf8mb4 */;
CREATE TABLE `outsources_outsourcebranch`
....

解決

DROP DATABASE & CREATE DATABASE して、更地にmysqldumpをロードする

資料

How to fix MySQL error 1215 Cannot add foreign key constraint

MySQL: JSON_OBJECT: JSON文字列フィールドを含む時のバックスラッシュ問題

Tue, 28 Mar 2023 00:00:00 +0000

`how to replace double back slash character to single one from MySQL JSON_OBJECT function results for column including JSON string`

You can use the MySQL function REPLACE() to replace double backslashes with single backslashes in a JSON object. Here’s an example:

1

SELECT REPLACE(JSON_OBJECT(column_name), '\\\\\\\\', '\\\\') FROM table_name;

This will return the column values with double backslashes replaced with single backslashes.

If you want to insert a JSON object literal with single backslashes instead of double backslashes, you can set the NO_BACKSLASH_ESCAPES SQL mode⁴. When this mode is set, a single backslash instead of double backslashes can be used to insert the JSON object literal, and the backslashes are preserved⁴. If you use the JSON_OBJECT() function when performing the insert and this mode is set, you must alternate single and double quotes⁴.

Snowfake: ビュー

Sat, 18 Mar 2023 00:00:00 +0000

Snowflake View

マテリアライズドビュー(`Enterprise Edition`)

マテリアライズドビューの使用

ベーステーブルで実行された DML の量に関係なく、マテリアライズドビューを介してアクセスされるデータは常に最新です。マテリアライズドビューが最新になる前にクエリが実行されると、Snowflakeはマテリアライズドビューを更新するか、マテリアライズドビューの最新部分を使用して、必要な新しいデータをベーステーブルから取得します。
CREATE MATERIALIZED VIEW
ビューとマテリアライズド・ビューの違いを理解する
Snowflake マテリアライズドビューについて
SnowflakeのMaterialized View
マテリアライズドビューとそのベーステーブルをクラスタリングするためのベストプラクティス

PostgreSQL

マテリアライズドビューの機能（PostgreSQL）
マテリアライズドビューの内容をテーブルの最新の状態と同じにしたいときには、REFRESH MATERIALIZED VIEWを実行します

MySQL

MySQLでMaterialized Viewを実現する
残念ながら、MySQLではデフォルトでMaterialized Viewを作る機能は存在しません。
トリガーかバッチで参照用のテーブルを作る

Snowflake: NDJSON format

Tue, 14 Feb 2023 00:00:00 +0000

`CREATE FILE FORMAT`

https://docs.snowflake.com/ja/sql-reference/sql/create-file-format

JSON

https://docs.snowflake.com/ja/sql-reference/sql/create-file-format#type-json

-- If TYPE = JSON
COMPRESSION = AUTO | GZIP | BZ2 | BROTLI | ZSTD | DEFLATE | RAW_DEFLATE | NONE
DATE_FORMAT = '<string>' | AUTO
TIME_FORMAT = '<string>' | AUTO
TIMESTAMP_FORMAT = '<string>' | AUTO
BINARY_FORMAT = HEX | BASE64 | UTF8
TRIM_SPACE = TRUE | FALSE
NULL_IF = ( '<string>' [ , '<string>' ... ] )
FILE_EXTENSION = '<string>'
ENABLE_OCTAL = TRUE | FALSE
ALLOW_DUPLICATE = TRUE | FALSE
STRIP_OUTER_ARRAY = TRUE | FALSE
STRIP_NULL_VALUES = TRUE | FALSE
REPLACE_INVALID_CHARACTERS = TRUE | FALSE
IGNORE_UTF8_ERRORS = TRUE | FALSE
SKIP_BYTE_ORDER_MARK = TRUE | FALSE

doctrine ORM

Thu, 06 Aug 2015 00:00:00 +0000

$ ./composer.phar require doctrine/orm 2.4.*
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
- Installing doctrine/collections (dev-master 3661cd8)
Cloning 3661cd8bc5152598dbe6772e98b78d1fa8281a67
- Installing doctrine/cache (dev-master e7b77e5)
Cloning e7b77e5abe230a2cc1db5005fb86435da213ae3b
- Installing doctrine/inflector (dev-master b0b2fef)
Cloning b0b2feffb47906a03b570777c07044c529d1d124
- Installing doctrine/common (2.5.x-dev 26727ba)
Cloning 26727ba78de21a824dcbfa5a8ab52c21fe7d71d5
- Installing doctrine/dbal (dev-master cc2d503)
Cloning cc2d50385efa1ea87f5d0afa2c47cc2499914f81
- Installing doctrine/orm (2.4.x-dev 0cf7e0e)
Cloning 0cf7e0e628c1409c9235c9b107c9623a2e8a80ef
doctrine/orm suggests installing symfony/yaml (If you want to use YAML Metadata Mapping Driver)
Writing lock file
Generating autoload files

MySQL

Wed, 05 Aug 2015 00:00:00 +0000

[intrinsic column flags]
- PK: primary key (column is part of a pk)
- NN: not null (column is nullable)
- UQ: unique (column is part of a unique key)
- AI: auto increment (the column is auto incremented when rows are inserted)
[additional data type flags, depend on used data type]
- BIN: binary (if dt is a blob or similar, this indicates that is binary data, rather than text)
- UN: unsigned (for integer types, see docs: "10.2. Numeric Types")
- ZF: zero fill (rather a display related flag, see docs: "10.2. Numeric Types")

MySQLでログを出力してみる

ERROR 2049 (HY000): Connection using old (pre-4.1.1) authentication protocol refused (client option ‘secure_auth’ enabled)

MySQLのバージョンがちがうとパスワードハッシュが違うのでログインできなくなる

Redis Windows

Tue, 21 Apr 2015 00:00:00 +0000

Redis-64 on Windows

Install

C:\Users\hdknr>choco install redis-64
Chocolatey v0.9.9.2
Installing the following packages:
redis-64
By installing you accept licenses for the packages.
redis-64 v2.8.19
ShimGen has successfully created a shim for redis-benchmark.exe
ShimGen has successfully created a shim for redis-check-aof.exe
ShimGen has successfully created a shim for redis-check-dump.exe
ShimGen has successfully created a shim for redis-cli.exe
ShimGen has successfully created a shim for redis-server.exe
redis-64 has been installed successfully.
Chocolatey installed 1/1 package(s). 0 package(s) failed.
See the log for details.

redis-server

C:\Users\hdknr>redis-server
[7308] 21 Apr 10:26:02.432 # Warning: no config file specified, using the defaul
t config.
In order to specify a config file use C:\ProgramData\chocolatey\lib\redis-64\redis-server.exe /path/to/redis.conf
_._
_.-``__ ''-._
_.-`` `. `_. ''-._ Redis 2.8.19 (00000000/0) 64 bit
.-`` .-```. ```\/ _.,_ ''-._
( ' , .-` | `, ) Running in stand alone mode
|`-._`-...-` __...-.``-._|'` _.-'| Port: 6379
| `-._ `._ / _.-' | PID: 7308
`-._ `-._ `-./ _.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' | http://redis.io
`-._ `-._`-.__.-'_.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' |
`-._ `-._`-.__.-'_.-' _.-'
`-._ `-.__.-' _.-'
`-._ _.-'
`-.__.-'
[7308] 21 Apr 10:26:02.455 # Server started, Redis version 2.8.19
[7308] 21 Apr 10:26:02.456 * The server is now ready to accept connections on port 6379

redis-cli

C:\Users\hdknr>redis-cli
127.0.0.1:6379> set testkey testvalue
OK
127.0.0.1:6379> get testkey
"testvalue"
127.0.0.1:6379>

StackExchange.Redis

NuGet

PM> Install-Package StackExchange.Redis

Windows Forms

1
2
3
4
5
6
7
8


 private void button1_Click(object sender, EventArgs e)
 {
 var connect = StackExchange.Redis.ConnectionMultiplexer.Connect("localhost");
 var cb = connect.GetDatabase(); // StackExchange.Redis.IDatabase

 cb.StringSet("name", "hdknr");
 MessageBox.Show(cb.StringGet("name"));
 }

Console Client

127.0.0.1:6379> get name
"hdknr"

PNGファイルの連結

Sun, 01 Mar 2015 00:00:00 +0000

imagemagick install

$ brew install ImageMagick
==> Downloading https://homebrew.bintray.com/bottles/imagemagick-6.9.0-3.yosemite.bottle.tar.gz
######################################################################## 100.0%
==> Pouring imagemagick-6.9.0-3.yosemite.bottle.tar.gz
Error: The `brew link` step did not complete successfully
The formula built, but is not symlinked into /usr/local
Could not symlink bin/convert
Target /usr/local/bin/convert
already exists. You may want to remove it:
rm '/usr/local/bin/convert'
To force the link and overwrite all conflicting files:
brew link --overwrite imagemagick
To list all files that would be deleted:
brew link --overwrite --dry-run imagemagick
Possible conflicting files are:
/usr/local/bin/convert
/usr/local/share/man/man1/convert.1
==> Summary
🍺 /usr/local/Cellar/imagemagick/6.9.0-3: 1440 files, 22M

$ rm '/usr/local/bin/convert'
override rwxr-xr-x root/wheel for /usr/local/bin/convert? yes
$ ls /usr/local/bin/convert
ls: /usr/local/bin/convert: No such file or directory
$ brew link --overwrite imagemagick
Linking /usr/local/Cellar/imagemagick/6.9.0-3... 71 symlinks created

Boostrap : nav

Wed, 25 Feb 2015 00:00:00 +0000

navbar
navbar-brand
navbar-collapse
navbar-default
navbar-form
navbar-header
navbar-nav
navbar-toggle
navbar-left
navbar-btn
navbar-text
navbar-link
navbar-right
navbar-fixed-top
navbar-fixed-bottom
navbar-static-top
navbar-inverse

データベース on hdknr blog

mysqldump エラー 1449: DEFINER が存在しないユーザーを参照している場合の対処法

なぜ起きるのか

DEFINER が問題のオブジェクトを特定する

急成長でぶつかったMySQLの罠とその向き合い方 - 7つの実践的な教訓

1. DDL 実行の落とし穴

2. MDL ベースのデッドロック

3. レプリカがライターに影響を与える問題

4. 同時リクエストによるデッドロック

ギャップロックパターン

DuckDB・Apache Arrow・Parquetの関係を整理する：列指向エコシステムの全体像

Parquet・Arrow・DuckDB の位置付け

DuckDB の高速性を支える3つの柱

1. 列指向ストレージ

2. ベクトル化実行エンジン

3. 自動並列化

redis-py の Lock をサブクラス化してフェンシングトークンを実装する

前提知識：Redis の Lua スクリプティング

なぜ Lua スクリプトが必要か

Redis CLI での実行例

redis-py での実行例

セキュリティ上の注意

Redisを「共有状態」として使うアンチパターン：キー設計の落とし穴

キャッシュと共有状態の違い

暗黙の契約に依存したデータ構造

「削除できないキー」問題

キーを「パブリック API」として扱う

補足：分散ロック基盤としての Redis

Software Design 2026年4月号の注目特集：PostgreSQL 18 高速化と MCP サーバー開発

第1特集：PostgreSQL 18 に学ぶデータベース高速化機能

章構成

第2特集：MCP サーバー開発成功の秘訣

章構成

RuView × Wi-Fi電波で壁越し人体検知 — $48で心拍・姿勢を丸裸にする技術の実態

RuView × Wi-Fi電波で壁越し人体検知 — $48で心拍・姿勢を丸裸にする技術の実態

話題の発端

RuView とは何か

主張されている性能

科学的な背景 — CMU「DensePose From WiFi」

論文の核心

CSI の仕組み（簡略版）

Redis Pub/Sub から Streams への移行で帯域 99% 削減 --- 同時接続 30 万超チャットの実践記録

Redis Pub/Sub から Streams への移行で帯域 99% 削減 — 同時接続 30 万超チャットの実践記録

背景 — Redis Cluster Pub/Sub のスケール限界

PolarDB

PolarDB for PostgreSQL

記事

Redis キーの作成時刻

Redis キーの登録日時

DRF: DataFrame を使って CSV エクスポート

DRF: DataFrame を使って CSV エクスポート

CSV レンダラー

DataFrame を返すリストシリアライザ

エクスポートするシリアライザを生成するメタクラス

実際のメタクラス

実際のシリアライザ

API 本体(ビューセット)

MySQL BULK INSERT

MySQL バルクインサート

MySQL only_full_group_by

only_full_group_by

MySQL 半角カナ検索

utf8mb4_0900_ai_ci

半角カナの濁点ありは照合順序の設定では解決できない

django-filter: method フィルターで対応

MySQL: ERROR 1553 (HY000): Cannot drop index 'uniq_profit': needed in a foreign key constraint

MySQL: ERROR 1553 (HY000): Cannot drop index ‘uniq_profit’: needed in a foreign key constraint

Django Migration の失敗

制約 検索

再設定

最終スキーマ

MySQL: ERROR 3780 (HY000) at line 1406622: Referencing column 'os_branch_id' and referenced column 'id' in foreign key constraint '***' are incompatible.

ERROR 3780 (HY000) at line 1406622: Referencing column 'os_branch_id' and referenced column 'id' in foreign key constraint '***' are incompatible.

原因

解決

資料

MySQL: JSON_OBJECT: JSON文字列フィールドを含む時のバックスラッシュ問題

how to replace double back slash character to single one from MySQL JSON_OBJECT function results for column including JSON string

Snowfake: ビュー

Snowflake View

`only_full_group_by`

制約検索

`ERROR 3780 (HY000) at line 1406622: Referencing column 'os_branch_id' and referenced column 'id' in foreign key constraint '***' are incompatible.`

`how to replace double back slash character to single one from MySQL JSON_OBJECT function results for column including JSON string`

マテリアライズドビュー(`Enterprise Edition`)

`CREATE FILE FORMAT`