以下、取得範囲が小さい順に記述する。
極力上部に記載されたメソッドを使用していけば問題が起きにくい。
fetchOne 1行目の値のみを返す
fetchRow 1行目のみを返す。※setFetchModeによりキーも取得する場合がある。
fetchCol 値のみを通常配列で返す
fetchAll 取得したデータ全てを返す※setFetchModeによりキーも取得する場合がある。
fetchAssoc キーと値を全て返す。※fetchAll + キー取得のsetFetchModeの強制
fetchParis 1つ目のカラムをキー、2つ目のカラムを値とする連想配列を返す。※fetchAssoc を使用すれば良いので最も使わない
使い分けが結構難解に感じるが、
弊社では以下のようなルールとしています。
件数取得:fetchOne
1行データ取得:fetchRow
複数行データ取得:fetchAll
使用を推奨しない
fetchCol キーが無いため
fetchAssoc fetchAllとfetchAssocの両方を使用すると混乱を招くため。
今思えば、fetchAllを禁止してfetchAssocを推奨したほうが
fetchModeを考えないで良いので、よりよい方法だったと感じる。
使用不可
fetchParis 無理やり用途を考えないと使えない。
開発者が多い場合にはfetchOneも禁止して、
fetchRowで代替させても良い。
さらに単純化するなら使用可能なメソッドはfetchAllだけにして
1行取得の場合には「limit 1」を付けるルールの方が、
色々と安全な気はする。
fetchOne, fetchRowのいずれも
記載したクエリ自体は実行されてしまうので、
意図せず2行以上返るような重いクエリを書いてしまった場合には
(データ量によっては)応答が返らない危険性がある(しかも気が付きにくいし)。
以上、プロジェクトごとに使い分けて頂ければと想います。
私が今、コーディング規約を作るなら
「使用可能なメソッドはfetchAllのみ。1行取得の場合にはlimit を付ける」ルールにすると思います。
cronからexpect を使ってみて、色々と逃げながら実装した
私の会社では運用補助ツールとしてteratermのマクロを使っています。
私が入社してからは運用で使用頻度が多い対話的処理などは殆どマクロ化し
なるべく運用にかかるコストを下げるように自動化をどんどん進めました。
ただ、クリティカルな部分ではどうしてもteratermのマクロは信頼できず
あくまで運用補助としての使い方が主な使い方でした。
信頼性という意味ではローカルのwindowsで動くプログラムは、
サーバー側のcronで動くものとは比べられないからです。
そしてサーバー側で対話的な処理を行うのであれば、
expectを使うことが一般的です。
expectはtclという言語仕様を用いており、
この言語仕様が昔からあるプログラムの割りには、
一癖も二癖もある言語なのです。
web上で情報を探してみたところ
比較的簡単なサンプルはあるものの、
本格的な記載を行っているページは以下くらいでした。
・expectで自動化
上記のページは本当によく書かれています。
おそらく数十時間は試行錯誤したのでは無いかと思われます。
ただ、私は結局の所、いくつかの問題の完全な解決策は
見つけることができませんでした。
また、もしexpectで困った場合にはネット上では情報は見つからないので、
tclの言語仕様を見たほうが良いです。
具体的に解決できなかった点は以下になります。
私はいくつかの問題が解決できなかったため、
cronからbashを呼び出し、対話的な処理のみexpectファイルを読み込むという
あまり綺麗とは言いがたい解決策を用いています。
シェルとexpectが混ざっていると、問題の切り分けがやりにくいこと、
特にクォーテーション、ダブルクォーテーション絡みの挙動の違いで
長時間悩んだたためです。
以下にとりあえず問題を突破するのに成功した、
mysqlのインポートスクリプトを書いておきます。
また、参考情報ですがデバックする際にはcronの起動ログは /var/log/cron
詳細ログは /home/ユーザー/mbox に入ります。
以上、参考になれば幸いです。
コメント(0)
2013.09.07
[
Myカテゴリ:技術の話
]
私が入社してからは運用で使用頻度が多い対話的処理などは殆どマクロ化し
なるべく運用にかかるコストを下げるように自動化をどんどん進めました。
ただ、クリティカルな部分ではどうしてもteratermのマクロは信頼できず
あくまで運用補助としての使い方が主な使い方でした。
信頼性という意味ではローカルのwindowsで動くプログラムは、
サーバー側のcronで動くものとは比べられないからです。
そしてサーバー側で対話的な処理を行うのであれば、
expectを使うことが一般的です。
expectはtclという言語仕様を用いており、
この言語仕様が昔からあるプログラムの割りには、
一癖も二癖もある言語なのです。
web上で情報を探してみたところ
比較的簡単なサンプルはあるものの、
本格的な記載を行っているページは以下くらいでした。
・expectで自動化
上記のページは本当によく書かれています。
おそらく数十時間は試行錯誤したのでは無いかと思われます。
ただ、私は結局の所、いくつかの問題の完全な解決策は
見つけることができませんでした。
また、もしexpectで困った場合にはネット上では情報は見つからないので、
tclの言語仕様を見たほうが良いです。
具体的に解決できなかった点は以下になります。
・以下のように標準入力「<」を使用する方法を見つけることができなかった
mysql < filename.sql
・expectのブロック内でシェル変数を呼び出すことがうまく行かなかった
以下を試しても全てうまく行かなかった。
send $aaa
send "$aaa"
send \"$aaa\"
send \"\$aaa\"
私はいくつかの問題が解決できなかったため、
cronからbashを呼び出し、対話的な処理のみexpectファイルを読み込むという
あまり綺麗とは言いがたい解決策を用いています。
シェルとexpectが混ざっていると、問題の切り分けがやりにくいこと、
特にクォーテーション、ダブルクォーテーション絡みの挙動の違いで
長時間悩んだたためです。
以下にとりあえず問題を突破するのに成功した、
mysqlのインポートスクリプトを書いておきます。
#!/usr/bin/expect
# タイムアウトを無制限(-1 )に設定する
set timeout -1
# [lindex $argv 0]は本プログラムが呼ばれた際の1番めのパラメータである。
# [lindex $argv] ならば全てのパラメータ
set command00 ""
append command00 mysql <\ [lindex $argv 0] "\n"
# spawn で管理するプロセスをシェルにしている
# spawn では標準入力、パラメータ、パイプ、リダイレクトなどが
# 正常に渡らず、実行できないプログラムが多かったため、
# 起動したいmysql ではなくシェルを起動している。
# 常にシェル起動したほうが無難な気がする
spawn /bin/sh
expect "sh-3.2"
# sendならば特に標準入力、パラメータ、パイプ、リダイレクトの制限が無いようである。
send $command00
expect "Enter password"
また、参考情報ですがデバックする際にはcronの起動ログは /var/log/cron
詳細ログは /home/ユーザー/mbox に入ります。
以上、参考になれば幸いです。
Template Designed By
ぐらいんだぁ
ぐらいんだぁ