「Got error 139 from storage engine」

というエラーを目にしたらそういう事です。

MySQLの微妙に痛い制限

Got error 139 from storage engine

InnoDB テーブル上の制約

VARCHAR、BLOB そして TEXT カラム以外の最大行長は、データベース ページの半分よりも少し短いです。これは、最大行長は約8000バイトであるという事です。LONGBLOB と LONGTEXT カラムは4GB 以下である必要があり、BLOB と TEXT カラムを含んだ合計行長は4GB 以下でなければいけません。InnoDB が行内の VARCHAR、BLOB、または TEXT カラムの最初の7684バイトを格納し、残りは別のページに格納されます。

このマニュアルの日本語が非常に分かり難い上に、原文だと7684バイトではなく、768バイトです。ちなみに768バイトが正解です。

何故、タイトルが10個かというと、768*10=7680バイトでほぼこの8KB制限に届いてしまうから。768バイトというとUTF-8では256文字というわけで、まぁ割と普通に有りえるサイズです。

リンク先二つ目のnix氏のブログによると設定による変更は不可という事なので、何だかなぁという仕様です。というか、にわかには信じ難い話なので私の読み違いか、検証違いだと信じたくなります。(アルファベットだけの世界ならこれぐらいの上限サイズで十分だよ、という事かもしれませんが)

とりあえずの回避策としては、テーブルを分割するか、カラムを統合するか、最大文字数制限を厳しくして稼ぐか、何にしてもテーブル設計や仕様に影響する事なのでしんどい話です。

ぼちぼちとピアノの練習をしているんですが、
左の薬指がうまく動いてくれません。
(写真は右手)

薬指の憂鬱

産まれてこの方全く意識した事は無かったんですが、
薬指はそういう指なんですね。

とは言え、右薬指は左に比べれば幾らか動くので、
左も慣れればある程度どうにかなるのかもしれません。

隠れアルゴリズマー集まれ

これは面白そうな問題。
やりませんが。

パッと思いつくのは、DOMを生成してDIV要素かTD要素(他にもあるかな？)の中から、最も文字数の多いものを本文要素として判定する方法。

ただ、これだと本文の文字数が少ないエントリーなんかで誤判定してしまいそうなので、加えて本文のテキスト自体から本文文章なのか、別の文章なのかを判断するような何かしらの処理が必要になりそうです。それでも、短い本文とそれよりも長いコメントが一つ付いたケースで正しく判定するのが難しそうですが。

或いは候補要素のブラウザ上での表示位置を取得して、上の方に表示されている候補を本文として選択するようなアプローチとか。


究極的な解決方法として、国内主要ブログサービス全ての本文部分に、それを意味するマイクロフォーマットを埋め込んでくれるようプログラムを修正してくれるプログラムとかはどうでしょう。

RFC1149を参考に適切なプロトコル及び高性能BOTを開発して、クロールさせれば実現出来そうな気がします。言ってみればGoogleの一歩先を行く試みです。

一方、ロシアは営業マンを使った。

Amazonで注文していた、SICPとオライリーのGauche本が届きました。

SICPは注文してすぐに来たのですが、Gauche本は予約していたにも関わらず、在庫切れでしばらく待つことになりました。結構売れているという事なんでしょうか。

併せて今年中には読了する予定です。

電子ピアノを買いました。




届いてみると予想よりでかかったです。窓辺に聳え立つピアノ箱。




買ったのはCASIOのPrivia PX-120DKです。




とりあえず置く場所に困ったのでベッドで寝てもらいました。
私はどこで寝ればいいんでしょうか。