sails で migrate されるテーブルのカラムの型定義
さいです。
サーバーサイドのフルスタックMVCフレームワークの sails.js を触ってます。
フルスタックなので migrate 機能があります。
モデル定義するだけで、アプリケーション起動時に自動でテーブル作ってくれるヤツですね。
sail.js のモデルは Waterline なのですが、どのストレージでも同じ型定義で記載できるよう、
integer
とか string
とかそんな型定義しかありません。
具体的に MySQL でどんな型になるんや!となったので調べました。
Watarline の型定義 -> MySQLの型定義の変換は sails-mysql
モジュールの
lib/sql.js にあります。
v0.12.1 時点だと以下のようになってるっぽいです。(大文字小文字問わない)
type | size | MySQL上の型 |
---|---|---|
string | N(省略した場合 255) | varchar(N) |
text | LONGTEXT | |
array | LONGTEXT | |
json | LONGTEXT | |
mediumtext | mediumtext | |
longtext | longtext | |
boolean | BOOL | |
integer | 8 | TINYINT |
integer | 16 | SMALLINT |
integer | 32(デフォルトサイズ) | INT |
integer | 64 | BIGINT |
float | FLOAT | |
double | FLOAT | |
decimal | DECIMAL | |
date | DATE | |
datetime | DATETIME | |
time | TIME | |
binary | BLOB |
ざっと見たけど、 unsigned を数値に設定する方法はないっぽかった。。。
同人誌即売会向けレジアプリ「レジプラ」を例大祭13で使用しました
こんにちは、さいです。
わたくし、趣味事として同人サークルを営んでおり、 東方Project や アイドルマスター等のキャラクターの グッズを制作して、同人誌即売会で販売しております。
https://sai-chan.com/rubberstrap.html
2016/05/08 に開催された 東方Projectオンリー同人誌即売会 博麗神社例大祭においても サークル参加してグッズを頒布させていただきました。
ところで、Twitter レジプラさんの下記のようなツイートを拝見しまして、 モニター登録をお願いしたところ、例大祭で使わせて頂けることになりました。
即売会向けレジアプリ「レジプラ」のモニター機貸し出しキャンペーン実施中。6月の正式販売前にモニター利用できるチャンスです。iPhone限定ですが、利用してみたい方はぜひご連絡下さい。レジプラで正の字カウントから卒業しよう! pic.twitter.com/lLEMvEXPSu
— レジプラ公式@技術書典A-01 (@tokyo_ff) 2016年5月5日
こんな感じでレジプラ土台と、さらにアプリインストール済みのiPhoneを貸して頂けました。
土台の中はこんな感じ。スイッチを入れるとコードレスで、 レジプラ土台とiPhone が接続されます。便利!
レジプラの商品登録画面
商品一覧画面
4つ目以降の商品はスライドさせると出てきます
お会計はこんな感じ。お釣りの額も自動で表示してくれるのがイカス!
そんな感じで、会場ではこんな感じで置いておりました。
弊サークルの名物、机を寂しく見せないために とりあえずグッズを並べるの図。
おかげさまでたくさんの方に足を止めて頂き、 盛況に終わりました!
レジプラさん、モニターとして使わせて頂きありがとうございました! 正式に販売される日を楽しみにしております!
当日、胸に貼ってたサークル参加証。 サークル参加証の入ったかばんを電車に忘れて、 再発行してもらうアホっぷりだった……
MySQL サーバーを再起動するとAUTO_INCREMENT の値が戻る
InnoDB では AUTO_INCREMENT のカウンタはメモリ上に保持します。
14.6.5.1 従来の InnoDB の自動インクリメントロック https://dev.mysql.com/doc/refman/5.6/ja/innodb-auto-increment-traditional.html
InnoDB テーブルに AUTO_INCREMENT カラムを指定すると、InnoDB データディクショナリ内のテーブルハンドルに、カラムに新しい値を割り当てる際に使用される自動インクリメントカウンタと呼ばれる特別なカウンタが含まれます。このカウンタは、ディスク上には格納されず、メインメモリー内にのみ格納されます。
InnoDB では、ai_col という名前の AUTO_INCREMENT カラムを含むテーブル t に自動インクリメントカウンタを初期化するために、次のようなアルゴリズムが使用されます。サーバーの起動のあとで、テーブル t への最初の挿入をするために、InnoDB は次のステートメントと同等なものを実行します。
SELECT MAX(ai_col) FROM t FOR UPDATE;
何が問題かというと、最新のレコードを削除して MySQL サーバーを再起動すると AUTO_INCREMENT の値が巻き戻る。
>select * from test; 1 2 3 4 5 >show create table test; CREATE TABLE `test` ( `id` int(10) NOT NULL AUTO_INCREMENT, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8; >delete from test where id = 5; >show create table test; CREATE TABLE `test` ( `id` int(10) NOT NULL AUTO_INCREMENT, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8; ここでMySQLを再起動 >show create table test; CREATE TABLE `test` ( `id` int(10) NOT NULL AUTO_INCREMENT, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8;
まあこのように SELECT MAX(id) FROM test FOR UPDATE;
の値に巻き戻る。
AUTO_INCREMENTした値が一意であることを見越して、
他のテーブルの外部キーにしてたりすると、整合性が取れなくなってしまう。
対策としては
・外部キー制約入れる
・AUTO_INCREMENTに頼らず、別に採番テーブルを用意する
・論理削除してレコードを delete しない(!)
toho-like-js を自分で作った
そのうち詳細はまた別に書きますが、自分で1から実装してみました。 まだ未実装箇所は多々あり、完コピにはなってません。
toho-like-js のソースコードを読む 5
進捗
TalkState ClearState GameOverState ShootingState
わかったこと
StageState からは 各要素の Manager インスタンスを通して要素を操作する。
toho-like-js のソースコードを読む 4
進捗
StageState を読んだ
わかったこと
1.ビット演算子でフラグ管理するの便利(キーの押下、SEの再生等)
2. 画面各要素のマネージャーインスタンス初期化時に、initDrawerを呼んでる
3.キー押下は一旦 KeyFlagQueue に格納され、キュー先頭から使用されていく
StageStateが持つ各シーン
ShootingState
ゲーム画面
TalkState
ボスキャラとの会話シーン
ClearState
ステージクリア
GameOverState
ゲームオーバー
画面の各要素
BackGround
Fighter
FighterOption
Enemy
Boss
Effect
Bullet
Bomb
EnemyBullet
Item
SpellCard
各要素毎に下記のクラスが存在する
Drawer
Factory
Manager
View
Element
FreeList
わからんこと
1.lag の役割(恐らく multiplay 用だと思う)
2.KeyFlagQueue クラスの必要性(恐らく通信プレイの同期のため)
3.viewScore で本来の score から表示の際に調整入れてる理由