NAME DBIx::Class::Storage::DBI::Replicated - BETA Replicated database support SYNOPSIS The Following example shows how to change an existing $schema to a replicated storage type, add some replicated (read-only) databases, and perform reporting tasks. You should set the 'storage_type attribute to a replicated type. You should also define your arguments, such as which balancer you want and any argum
Intro to DBIx::Class In my opinion DBIx::Class is one of the best ORM solutions out there. Not only can it model your database, including mapping out any foreign key relationships, it can also be used as a canonical point of reference for your schema. This means we can use it not only as an application layer interface to the database, but can also define a versioned database structure using the
Windows 10 の入ったディスクのバックアップが clonezilla で外形的にできることがわかった Posted on Jun 27, 2020 Windows10 が載ってるディスクに破壊的な変更加える前にバックアップしたくて、SystemRescueCd で clonezilla 使ってディスクまるごとイメージ化した(内部的には partimage が使われてる?)。 でこれ、レストアしたら起動する状態まで持っていけるんかな? すんごく不安だ。。。 — woremacx (@woremacx) June 15, 2020 systemrescuecd に同梱されている clonezilla を使ってまるまる取った Windows 10 のバックアップが戻せるか不安で仕方なかったので、VirtualBox に戻せるか試した。 そもそもなぜ clonezilla を試したかったの
Kazuho@Cybozu Labs: フレンド・タイムライン処理の原理と実践 奥さん本人の中でブームが去った感もあるRDBMSで実現するフレンド・タイムライン処理ですが、そういえばDBICで使ってみたのを思い出したので晒してみます。 要はDBICからストアドプロシージャの叩き方を知りたかっただけなんですけどね。 パッケージ名はWebインターフェースはどーせCatalystで作るでしょってことでCatalyst + Twitter = Catatter…って安直なネーミングですね。 記事中ではプッシュ型とプル型が紹介されているのですが、データ量やfollow, removeの際のコストとか考えたらプル型の方が好みかなってことでプル型を採用してみました。 また、基本的にスキーマやストアドプロシージャはオリジナルと同じですが、DBICでPKをマルチカラムにするとめんどっちーのでサロゲートキーを
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
DBICで簡単にお金が借りることができます（ちが まあ、面白くないのでやめておきますが、DBICは かなりパフォーマンスに気を使った設計なのは周知の事実なのでつが、 キャッシュを使うことでよりパフォーマンス向上が図れます。 例えば my $itr = $self->model('Member')->search({},{}); while (my $member = $itr->next) { warn $member->id; } $itr->reset; while (my $member = $itr->next) { warn $member->id; } こんな感じの処理があったとします。 Memberテーブルを二度処理するみたいな。 ちなみに同じオブジェクトを使う時は $itr->reset; こうしてやればイテレータがリセットされます。 この場合、２個のwhileのところでそ
DBIx::Class::ResultSetManager - scheduled for deletion in 09000 - search.cpan.org DBIx::Class::ResultSetManager never left experimental status and has now been DEPRECATED. This module will be deleted in 09000 so please migrate any and all code using it to explicit resultset classes using either __PACKAGE__->resultset_class(...) calls or by switching from using DBIx::Class::Schema->load_classes()
DBIx::ClassでmysqlのFULLTEXTインデックスに対する検索をより美しく使うにはどうすればいいかなぁ、と考えた結果search_literalを使えば良いかと思い立った次第です。 こんなテーブルで CREATE TABLE table01 ( id INT UNSIGNED AUTO_INCREMENT NOT NULL, PRIMARY KEY(id), title VARCHAR(255), artist VARCHAR(255), review TEXT, FULLTEXT(review) ); Schemaを作って、こんな感じに走らせると use strict; use warnings; use CD::Schema; my $schema = CD::Schema->connection('dbi:mysql:cd', 'user', 'password');
SQL::AbstractとMySQLのFulltext Search DBIx::Class経由でSQL::Abstractを使っているわけですが、このたびPostgreSQLからMySQLに引っ越ししようかと思ってるサービスがありまして、そこで問題にぶち当たりました。 Ludia(PostgreSQL)の場合は対象のカラムに対してオペレーターをかますので、column => { '@@' => '*D+ ....' } （新しいLudiaは%%か）とかできるわけですが、MySQLの場合はMATCH(...) AGAINST(...)を使うので カラム→オペレーター→引数という形にできない。 もちろん 'MATCH(...)' => \'AGAINST(...)'ってやってもいいんだけど、なんかわかりにくい気がしてた。 で、色々考えた末、これが俺の中で一番きれいという判断となった $sq
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
