DBICでテーブル名切替の術 - Hatena::Diary::Neko::kak 500 Internal Server Error
アプリを作ってると色々ログ系をDBに保存しておきたかったりするのですが、 ログテーブルって結構でかくなってしまう運命です。 DBによってはテーブルサイズがでかくなると検索効率が落ちてしまったり ちょくちょく問題になってしまうのですが、 ログテーブルを年月ごととかで分割すると結構さくさく扱えたりします。 ただ、普通にDBIC使ってると分割したログテーブル毎にスキーマを用意する必要が でてきてしまうです。 例えば access_logってテーブルがあるとして、これを年月で分割して保存させるばやい、 access_log : Proj::Schema::AccessLog access_log_200706 : Proj::Schema::AccessLog200706 access_log_200707 : Proj::Schema::AccessLog200707 access_log_20
blog.woremacx.com: DBIC が生成する SQL をログってみる
Windows 10 の入ったディスクのバックアップが clonezilla で外形的にできることがわかった Posted on Jun 27, 2020 Windows10 が載ってるディスクに破壊的な変更加える前にバックアップしたくて、SystemRescueCd で clonezilla 使ってディスクまるごとイメージ化した(内部的には partimage が使われてる?)。 でこれ、レストアしたら起動する状態まで持っていけるんかな? すんごく不安だ。。。 — woremacx (@woremacx) June 15, 2020 systemrescuecd に同梱されている clonezilla を使ってまるまる取った Windows 10 のバックアップが戻せるか不安で仕方なかったので、VirtualBox に戻せるか試した。 そもそもなぜ clonezilla を試したかったの
DBIx::Class で sql_maker が生成した SQL をロギングする方法
DBIC いろいろ使って検証を続けているのですが、O/R Mapper って当たり前だけど万能じゃぁないなぁ〜とすごく思う今日この頃。正直、リレーションとか張りまくってる場合、自前で JOIN とか View 定義して書いた方が遙かに効率の良い SQL が記述できる。 複雑な SQL を表現するには、O/R Mapper だと逆に見づらいなぁ〜と思ったり。 とはいえ、単純な SQL の場合はやはり便利。コードも見た目、OO っぽくてかっこいいし。 でも、どうにも解析できなかったことが一つ。DBIC しか見てないんですが、sql_maker が生成した SQL をロギングする方法がわかりません。なんかコードを深追いしていくと、 メンドウなので、モジュールにしてなくってとってつけたような感じで実現。たとえば、Catalyst だと MyApp.pm で use UNIVERSAL::requi
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
