カテゴリー : 2010年 5月

100万件規模のテーブル移行

データ量が多いと、PhpMyAdminでぽんっというわけにはいかなくなりますよね。テーブル移行。

インポートの時にエラーになってしまいます。

今回は、対象件数100万件程度のテーブルをmysql→mysqlに移行したので、記録。

基本的な流れは、phpMyAdminでエクスポート、それをbigdump.phpでアップロード。

1.エクスポート

まずは通常通り、phpMyAdminからエクスポート。このとき、gzip形式のDLにチェックボックスを入れておくと、容量を節約できる。

bigdump.phpは50MBまで(というか、サーバー側の制約)しかあげられないので、件数を調整して、50MB程度に収まるようにする。

全件いっきにやらない場合は、開始行と件数を調整。

2.bigdump.php取得

http://www.ozerov.de/bigdump.php

↑↑↑

ここから取得

3.ファイルの編集とアップロード

bigdump.phpに、アクセスするための情報、ホストやらDB名やらを記述。((37行目から)

$db_server   = ‘localhost’;
$db_name     = ”;
$db_username = ”;
$db_password = ”;
// Other settings (optional)

bigdump.phpと、さきほどエクスポートしたファイルを同フォルダにアップロード

4.実行

bigdump.phpにアクセスして、画面上からエクスポートファイル(SQLファイル)を選択すればOK

以上です。

意外に簡単に実行できました。

便利なモンです。

OPENPNEで、全員フレンド機能の実装

OPENPNEで、登録した会員は全員、お友達でいいよ!という場合に、ユーザ新規登録時に、フレンドリストを更新しちゃおうという機能。

企業SNSや、特定の目的のみのユーザでSNSを構築する場合、お友達機能は不要なことがあります。

全員、仲間でしょう!というとき。

そんな状況のために、全員をマイフレンドにする機能を実装したので、記録。

環境はOPENPNE3

1.お友達情報は、member_relationshipというテーブルに格納されている。

基本的に、このテーブルを更新するだけでOK。

id 登録順に連番
member_id_to 対象メンバーのID
member_id_from 主体メンバーのID
is_friend 友達かどうか
is_friend_pre 友達承認待ちかどうか
is_access_block アクセスブロックしているかどうか
created_at 作成日時
updated_at 更新日時

ソースは下記

$sql = “select id from `member` where is_active=’1′ and id!=’$myNumber'”;
$result = $db->queryAll($sql);
if (MDB2::isError( $result )) {
die($result->getMessage());
}
print_r($result);
$types = array(‘integer’,’integer’,’integer’, ‘text’, ‘text’);
$table=”member_relationship”;
$prepare=”INSERT INTO $table VALUES (:id, :name, :lang)”;
$sth = $db->prepare(
‘INSERT INTO ‘.$table.’ (
`member_id_to` ,
`member_id_from` ,
`is_friend` ,
`created_at` ,
`updated_at`
) VALUES (:to, :from, :is_friend,:create , :update)’, $types);
if (PEAR::isError($sth)){
echo $sth->getDebugInfo();
exit();
}
foreach($result as $member){
$id=$member[0];
if($myNumber==$id){
continue;
}
print $id.”hello<br>”;
$data[to]=$id;
$data[from]=$myNumber;
$data[is_friend]=1;
$data[create]=date(“Y-m-d H:m:s”);
$data[update]=date(“Y-m-d H:m:s”);
$affectedRows = $sth->execute($data);
}

上記のようなソースでOK.

ただ、これだと、何度も実行した場合に、重複してレコードができてしまう。

その場合、toとfromのセットがUNIQUEじゃないとダメっていうチェックがDBのほうに入ってるから、エラーになるんだけども、気になる人は、しっかりチェックしてからinsertしてください。

2.ユーザ登録時に、自動的に実行する。

これにちょっとハマった。

ユーザ登録時、どこで処理をおこなっているのか、わかりにくかったので。

PNE2系だとぽろぽろ情報がでてくるんだけど、PNE3だとどうも情報が少ないですね。

結論からいうと、lib/action/opMemberAction.class.phpのexecuteRegisterInputに記述してやればOK.

さきほどのソースに、$this->idを渡してあげればOK.

上記ソースをfunction化してあげて、$this->idを渡すのがよさそう。

以上です!

WordPressMuインストールについての覚書

ポータルサイト構築中、ブログを自動的にインストールする必要にかられて、WordPressをシステム的にインストールする方法を調査したので、記録。

最初は、

  1. wordPress.zipをサーバ某所においておく
  2. usrMake()がよばれたら、wordPress.zipをusrディレクトリに展開
  3. wp-config.phpを自動生成
  4. パーミッション調整

ていう手順でいけるかなーと作っていたんだけども、ふとしたところで、WordPressMUの存在に気づいたので、入れてみた。

すこぶる便利。

手順は以下。


1.WordPressMuのダウンロード

http://mu.wordpress.org/download/

2.設定は、ウィザードに従っていけば簡単

特に難しいところは無し。

3.テンプレートを編集可能にする

デフォルトだと、管理画面からテンプレートの編集は不可能。

そこで、PHPファイルを書き換えて、可能にする。

/wp-admin/includesフォルダ内の、mu.phpを編集。

①現行v2.8.6なら、556行目にある、
“unset( $submenu[‘themes.php’][10] ); // always remove the themes editor”
という項目の頭に、//を付けて、
“//unset( $submenu[‘themes.php’][10] ); // always remove the themes editor”
②現行v2.8.6なら、1128行目にある、
“if ( strpos( $_SERVER[‘PHP_SELF’], $page ) ) {”
とい項目を以下の様に変更。
“if ( strpos( $_SERVER[‘PHP_SELF’], $page ) && !is_site_admin() ) {”

http://active-oita.com/subekoro/blog/archives/485 参照

4.自動ユーザ登録のための手順

ここから先は、普通は必要無し。

今回の開発では、クライアントの要望で、システム的にユーザ追加の必要があった。

まずは、単純に、下記URLのソースから、フォーム部分を持ってきてfile_get_content()でキックしようとしたけども、失敗。

http://an.koutaigu.com/blog/wp-admin/wpmu-blogs.php

管理者権限でログインした状態でないとダメらしい。

そりゃそうだ。

仕方が無いので、ソースを見てみて、直接、内部でユーザ登録をしている部分の関数を引っこ抜くことにする。

該当部分は、wpmu-edit.phpの、Addblogの部分。

ここをまるっとコピーして、少しだけ編集して、usrMake.phpを作成。

変更部分は、下記のとおり。

require_once(‘../wp-load.php’);

require_once(ABSPATH . WPINC . ‘/registration.php’);

print $current_site->domain;

//check_admin_referer(‘add-blog’);

コピペした段階だと、必要なrequire_onceが呼ばれていないので、最初にwp-loadとregistrationを呼んでおく。

そして、check_admin_refererを呼んでいる部分をコメントアウト。

あとは適当なHTMLファイルから、POSTでデータをusrMake.phpに渡してあげればOK。