MySQL :: MySQL 8.0 リファレンスマニュアル :: 13.1.9 ALTER TABLE ステートメント
SAVEPOINT、ROLLBACK TO SAVEPOINT および RELEASE SAVEPOINT ステートメント
[DBIx::Class][Perl] Cache::Memcached と DBIx::Class - cyberlib.enterbrainz.com
[DBIx::Class] [Perl] Cache::Memcached (Cache::FileCache,Catalyst::Plugin::Cache::Memcachedも) はオブジェクトがキャッシュできる。とても便利。 でもDBIx::Classのオブジェクトは、キャッシュできないことがある。 サンプル： #!/usr/bin/perl use strict; use Cache::Memcached; use TestDB; my $memd = new Cache::Memcached {'servers' => [ "127.0.0.1:11211" ]}; my $schema = TestDB->connect("dbi:mysql:testdb;localhost",'user','password'); #OK pattern
memcached: a distributed memory object caching system
What is Memcached? Free & open source, high-performance, distributed memory object caching system, generic in nature, but intended for use in speeding up dynamic web applications by alleviating database load. Memcached is an in-memory key-value store for small chunks of arbitrary data (strings, objects) from results of database calls, API calls, or page rendering. Memcached is simple yet powerful.
mixi Engineers’ Blog » 新RSS Crawlerの裏側
このブログでは初めましての長野雅広(kazeburo)です。mixi開発部・運用グループでアプリケーションの運用を担当しています。 12月12日よりmixiのRSSのCrawlerが改善され、外部ブログの反映が今までと比べ格段にはやくなっているのに気付かれた方も多いかと思います。この改善されたRSS Crawlerの裏側について書きたいと思います 以前のCrawlerについて 以前のCrawlerは cronからbrokerと呼ばれるプログラムを起動 brokerはmember DBから全件、idをincrementしながら取得し、外部ブログが設定されていればcrawlerを起動(fork) crawlerはRSSを取得しDBに格納して終了 このような設計になっていました。 この設計の問題として、member DBを全件走査するという無駄な動作と、一件一件crawlerを起動するためオーバ
PRIMARY KEY制約(主キー/プライマリキーを設定する)
プライマリーキー(主キー)とは作成したテーブルの中の1つまたは複数のカラムの組み合わせに対して設定するもので、テーブルに格納されているデータをに格納されているデータを識別するための目印のようなものです。ここではプライマリキーについての簡単な解説と、 MySQL のテーブルでプライマリキーを設定して利用する方法について解説します。 テーブルを作成したあとにプライマリーキーを作成したり、作成したプライマリーキーを削除する方法については「インデックスの作成」を参照してください。 プライマリーキー(主キー)とは 最初にプライマリーキーについて簡単にご説明します。テーブルには多くのデータが含まれており、 1 つ 1 つのデータには複数のカラムの値が格納されています。格納されたすべてのデータの中から 1 つのデータを特定したいときに、 1 つまたは複数のカラムの値を検索してデータを特定しますが、その時
正しいメールアドレスのチェック方法
(Last Updated On: )正しいメールアドレスのチェック方法がちょっとした話題になっているようです。Web屋のネタ帳でも取り上げられていますが、メールアドレスのチェック方法自体は解説していません。ついでなので書いておきます。 「本当に正しいメールアドレスかチェック」するには実際にメールを送信して、送信されたユーザしか知り得ない情報をユーザが知っている事により確認しなければなりません。これはWeb屋のネタ帳で解説されている通りです。 安全でより確実なメールアドレスのチェック方法 きちんと正規表現でメールアドレスをチェックするのは面倒です。しかも、RFCを守らない大手企業もあり、正規表現でチェックするのは諦めるのが妥当でしょう。 記入されたメールアドレスが正しいかチェックする手順 @でスプリット（分割）する 配列要素数が2つかチェック。NGはエラー 1つ目の要素（ユーザ名部分）およ
[Catalyst][DBIx::Class][MySQL] MeCab-Senna-TritonnのRPMインストールとCatalystでのSearch - cyberlib.enterbrainz.com
※Fedora7を使用 [mecab導入] 楽だ。 yum -y mecab mecab-devel mecab-ipadic perl-mecab [senna導入] cd /home/hoge/rpmbuild/SOURCES wget http://iij.dl.sourceforge.jp/senna/25607/senna-1.0.7.tar.gz tar xzvf senna-1.0.7.tar.gz SPEC発見。 cp senna-1.0.7/senna.spec /home/hoge/rpmbuild/SPECS/. cd ../ rpmbuild -bb SPECS/senna.spec あら、エラーが出た。 error: File /usr/src/redhat/SOURCES/libsenna-1.0.7.tar.gz: No such f
[MySQL] mysqlの便利だけど忘れるコマンド - cyberlib.enterbrainz.com
[MySQL] チェック check table country,format,stock; チェック2 check table goods extended; リペア repair table country,format,stock; 最適化 optimize table country,format,stock; インデックスのみ最適化 analyze table country,format,stock; 置換 update goods set review=REPLACE(review,'<','<'); update goods set format=REPLACE(format,'"','"'); update goods set title=REPLACE(title,'&','&'); ファイル書き出し（エクスポート
[DBIx::Class] DBICでLEFT JOIN - cyberlib.enterbrainz.com
[DBIx::Class] from アトリビュートを使用する。 http://search.cpan.org/~ash/DBIx-Class-0.08008/lib/DBIx/Class/ResultSet.pm#from belongs_to を使用してリレーションしていると 普通の join (INNER JOIN) となる。 場合によって、left join を使用しなければならない時、 以下のように from アトリビュートを使用する。 my $it = $schema->resultset('Goods')->search( { 'stock.quantity' => {is => undef}, }, { columns => [qw/goods_id/], from => [ { me => 'goods' }, #ここで
resultset_attributes - Hatena::Diary::Neko::kak 500 Internal Server Error
DBICのresultset_attributesを使うとデフォルトの検索条件とか ソート条件を指定できます。 package Your::Schema::User; use strict; use warnings; use base 'DBIx::Class'; __PACKAGE__->table('user'); __PACKAGE__->resultset_attributes({ order_by => 'id DESC'}); ... 1; こんな感じでresultset_attributesを指定しておいてやると デフォルトでid DESCになってくれる。 例えば $self->model('User')->search( { name => 'nekokak' } )->first;こんなのを実行すると SELECT me.* FROM user me WHERE nam
MySQL の order by rand() - naoyaのはてなダイアリー
MySQL のレコード取り出しの際に、ソートをランダムにできないものかと調べていたら、あった。 SELECT * FROM table ORDER BY RAND()こんな感じで。ソートを RAND にすれば良いという… そうそう、僕もこれは最近知ったんですが。Haropy でエントリーをランダムに取り出すのにも order by rand() を使ってます。Class::DBI::mysql に retrieve_random というメソッドがあって、ランダムに一見取り出すことができるという。これも中では order by rand() limit 1 をやってます。 ただ、この rand() はデータ量が大きいテーブルには使いづらいという罠。 mysql> explain select id from entry order by rand() limit 1 ?G *********
負荷対策概論 - Y-110's Wiki
最新文章 2018-12-26 17:10▪ 致敬英雄，致敬不朽的精魂 2018-12-26 17:10▪ 四十年来闵行人的文化生活史一幕幕回放 2018-12-26 17:10▪ “笔尖上的童画”——欢图学员作品成果展将在东方网文化活动... 2018-12-26 17:10▪ “金色热线”12月27日将迎来年终特别节目 2018-12-26 17:10▪ 北京市发布持续低温蓝色预警信号 2018-12-26 17:10▪ 北京市网信办推进自媒体账号专项治理关闭11万个 2018-12-26 17:10▪ 有创意的崇明“橘农”让梦想和情怀扎根农场 2018-12-26 17:10▪ 突发！上海地铁3、4号线晚高峰运行延误系人员进入线路 2018-12-26 17:10▪ 中国经济总量将达90万亿关键时刻传递重要信息 2018-12-26 17:10▪ 海底捞："吃出卫生巾"系人为当事顾客
DBIx::Class::ResultClass::HashRefInflator - Hatena::Diary::Neko::kak 500 Internal Server Error
とかいうのがDBICのCoreに入りました。 使い方は簡単？で use DBIx::Class::ResultClass::HashRefInflator; my $rs = $self->model('Blog'); $rs->result_class('DBIx::Class::ResultClass::HashRefInflator'); my $member = $rs->single({rid => 'HXOK7cI4DA'}); warn Dumper $member; こんな感じでresult_classに設定してやると 結果として $VAR1 = { 'timestamp' => '2007-01-18 17:03:06', 'member_id' => '15', 'created_on' => '2007-01-18 17:03:06', 'id' => '34', '
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
全オペレーティング・システムのJavaのダウンロード一覧