このアカウントは、notestockで公開設定になっていません。
kb10uy(@kb10uy@mstdn.maud.io)の投稿
もみあげの長い美少女の話ばかりしています
Avatar icon: [𝕏] CamemBellcheese
Header: [𝕏] generalcanon
各種フレコ:
beatmaniaIIDX(八段): 1751-5340
オンゲキ(15.8): 3067667719792
Arcaea(◆9): 433827474
このアカウントは、notestockで公開設定になっていません。
「描画するメッシュは同じで位置情報だけ違うのを大量に描画する」というの、「対象カラムは同じでパラメーターだけ違うのを大量に INSERT する」とそっくりだと思いませんか
GPU Instancing になぞらえて Row Instancing みたいな名前で誰か実装してそう
午前中に言及した「prepared statement が RDB サイドでインスタンシングされてほしい」ってのはこれで、プレースホルダーに詰めるデータ全部配列に詰めておいたバッファと VALUES (...); だけの SQL を渡して詰め直しは RDB 側でやってくれるシステムがあったら素敵だよね、と思うわけです
prepare したところでカッコが 1 つだと各行ごとにアプリ側に制御が帰ってきて効率が悪いのはわかるんだけど、それの対処として VALUES の後ろを機械的に増やすのはあまりにも不毛すぎる
あ、もうひとつ不毛な SQL 生成といえば VALUES のカッコを 100 個ぐらい並べて手動でバッチングするやつがある
あるいは id IN ([..?]) みたいなプレースホルダを受け付けてそこに配列を渡したら展開されるみたいな仕様が入るのでもいい どちらかというとこっちのほうがみんなのためになる気がするが
('?' * length).join(',') 割とノイズになるので単純な SQL 文字列とパラメーターバインディングぐらいしか提供しないインターフェースでもこれをうまく処理する機構が入ってほしいんですよね(sqlx crate には提案があった気がする)
配列を渡すとあくまで配列オブジェクトのままパラメーターに挿入されてしまうので都合が悪く、 ?, ?, を生成するはめになりがち
これの話だと Rust の sqlx で IN 句にガっとデータ入れたいときにちまちま bind しないといけないのがつらいねというのがあります
Laravel でいえば Eloquent を含まない Fluent コンポーネントとか、あと knex.js とかね
関係マッパーじゃなくて単純なデータマッパーと都合の良いクエリビルダーがあれば良いだけの回、それなりにございます
クエリごとに欲しい結果は違うんだからテーブルに対応したモデルだけあってもしょうがなくない？と思うことはあるがこれは ORM を使わん奴の発想なんだよな
ORM 、クエリビルダの部分はともかくとしてマッピングの部分も使う場合はちゃんと仕様を把握しないとすぐに N+1 とかを引きがちというイメージがある
ぴけしの水ようかんテクスチャを適用しました
https://mstdn.maud.io/@pikepikeid/102527407487434362
ライブラリ掘り返してたら初代 Just Cause 出てきたんだけど 2006 年なだけあってブルーム全開でわろてる
モーメントとは違う機能として存在してるんですよ
https://twitter.com/kb10uy/timelines/1030079092131999744
みんな使ってると思ってたのに意外と誰も使ってない機能として TweetDeck からしか操作できないコレクションと Steam のコレクションがある
電車でGO! FINAL 小学生ぐらいのころほしかったけど結局プレイできずにサポート環境が無くなってしまった
人はオンゲキの譜面を見て「腕足りなくね？」と言うが僕からすると maimai のほうがよっぽど足りないのである(？)
このアカウントは、notestockで公開設定になっていません。
