カテゴリー : php

[Symfony1.4]factories.ymlでtimeoutを設定してるのに30分でセッション切れ現象が

C789_tokeiwokakuninsurudansei

先週のぶらぶら部の日記を書こうと思い、早1週間が経過してしまいました。

記事は明日明後日で書きますすみません。

その前に、技術メモ。

自社Webアプリのセッションタイムアウト時間を伸ばそうと言う事で、factories.ymlにタイムアウト秒を以下の通り設定してました。

user:
  param:
    timeout: 28800

よっしゃ!これで8時間はログアウトせーへん!勝つる!

と思っていた矢先

( ’`)<これ30分無操作でセッション切れちゃうんだけど…。

ななななんですとー!!

と思って調べていたらこんな記事が。

[symfony]symfonyのユーザ自動ログアウトとセッションタイムアウトについて

factories.yml 設定ファイル (1_4) – Symfony1.4

予期せぬふるまいに遭遇しなくてすむように、ユーザークラスはセッションガベージコレクタの有効期限の最長 (session.gc_maxlifetime) をタイムアウトよりもはるかに長く設けます。

symfony.com

あれっと思ってサーバのphp.iniを確認したら…

session.gc_maxlifetime=86400

KO☆RE☆DA

と言う訳で、結局30分くらいでSymfonyでのログイン状態が解除されてしまうのは、php.iniのsession.gc_maxlifetimeが原因でした。

その後値をさらに上げてiPhoneでタイマーを40分にセットして、カップラーメンを13個を作った所で動作確認。

うん、問題無しです。

それにしても86400秒(24分)って、なんでこんな微妙な数値に…。

とりわけ、原因がわかってよかったよかった。

ちなみに、この記事は電車の中から書きました。

mac book airがほしいれす。


[Doctrine]リレーションを使ってViewに項目を表示させる

技術メモです。
変数名やテーブル名がhogeではなく以下の様になっているのは

完全に私の趣味だ(キリッ

ではではさっそく。

先ずはschema.ymlの定義から
≪schema.yml≫

KneeHighGirl:
  connection: doctrine
  tableName: knee_high_girl
  columns:
    id:
      type: integer(8)
      fixed: false
      primary: true
      autoincrement: true
      .......中略
  relation:
    Girl:
      type: one
      local: girl_id
      foreign: id



書き終わったら、次に/lib/model/base/の中にあるBase.classにschemaに記述した通りに以下を追加する
ちなみに、相手先データが単数の場合はhasOneですが、
相手先が多の場合にはhasManyになるので注意して下さいね

≪BaseKneeHighGirl.class.php≫
    public function setUp()
    {
        parent::setUp();
        $this->hasOne('Girl', array(
             'local' => 'girl_id',
             'foreign' => 'id'));
    }




そしてリレーションで設定した項目を取得するためのメソッドやらを
/lib/model/KneeHighGirlTable.classで定義しましょう
≪KneeHighGirlTable.class.php≫
class KneeHighGirlTable extends Doctrine_Table
{

    public static function getInstance()
    {
        return Doctrine_Core::getTable('KneeHighGirl');
    }

    public function getKneeHighGirlsWithParams($params = null)
    {
        //ここでKneeHighGirlテーブルのレコードを全て取得
        //エイリアスでkhgを指定
        //その後は取得条件をleftJoinで追加していく宜し
        $query = $this->createQuery('khg');
        
        //ここでkhgに対するリレーションを辿ってレコードを取得
        //KneeHighGirlテーブル⇒Girlテーブル
        $query->leftJoin('khg.Girl gl');
        //ここでGirlからさらにリレーションを辿ったレコードを取得
        //Girlテーブル⇒Humanテーブル
        $query->leftJoin('gl.Human hmn');
        
        $query->orderBy('khg.id DESC');
        return $query;
    }
}



此処までいったら下準備は完了です
実際にActionで、pagerにセットする様に記述していきます
≪action.class.php≫
$this->pager = new sfDoctrinePager('KneeHighGirl');
    $this->pager->setQuery(Doctrine::getTable('KneeHighGirl')->getKneeHighGirlsWithParams($Params));
    $this->pager->setPage($request->getParameter('page', 1));
    $this->pager->init();
    $this->kneeHighGirls = $this->pager->getResults(Doctrine::HYDRATE_ARRAY);




奴は四天王の中でも最弱・・・
もう終わったも同然
食ってやるわ!!!!!!!!
view側でそれを受けてforeachで回して、セットするだけ
左手も添えるだけ
≪index.phpとかView側≫
foreach ($kneeHighGirls as $kneeHighGirl){
    <tr>
      <th>性別</th>
      <td><?php echo $kneeHighGirl['Girl']['Human']['sex'] ?></td>
    </tr>
}
[‘Girl’]・・・KneeHighGirl⇒Girlへのリレーション
※schema.ymlで定義した名前
[‘Human’]・・・Girl⇒Humanへのリレーション
※schema.ymlで定義した名前
[‘sex’]・・・Humanテーブルの中のカラム

こんな感じで、存外簡単に取得できる事が判ります
もともと、リレーションをなぜか使わない方向でやっていたのですが
pagerにセットする辺り、こうせざるを得なかったので。

大体1時間程度で解読できたのが、救いですな・・(*´ω`)w


ベトナムはハノイに出張中

お元気ですか、紅緒です。ハイカラさんと呼んでください・・
冗談はさておき、日曜からベトナムハノイへ6月初めの水曜まで出張してます。
オフショア開発の会社さんの中でプログラム叩いたり、お互い改修に関する不明点を通訳さん介して仕事したりしてまする。

ちなみにハノイ、この時期は雨期なんですが現在あまり雨も降っておらず。
温度は最高気温40度とか、なかなか殺しに掛かってますが建物の中は割とクーラーが効いてて快適だったり。
そして飯がうまい!以前ホーチミンへ行ったときはちょっとなぁあ・・と思ってましたが、現地の方がよく食べてる所を紹介してもらっていくと、これがうまいのなんの。
空芯菜の炒め物、生春巻、コロッケ的な何か、亀(すっぽんみたいな変な亀 から揚げとかで出てきます)
なかなかに快適です。ビールうまいし。

今回は仕事がメインなので、なかなか写真を撮影する機会はないですが、少しだけでも撮った奴は帰国後にうpしましょう。



さて、ここからはPHPのお話に戻りまして。
新規機能を開発していく中で、とりあえずバリデーションを通す事を第一目標にしていた為に起きた問題です。
共通機能の多い、他の機能よりhogeForm.classの内容をほぼコピーしてきて、当面はイラネ(゚⊿゚)とほぼ全てのバリデーションををコメントアウトしていたのですが
DBに保存したときに、なぜか値が0埋めだったりしてる。。
Save()メソッドの手前で変数をインスペクションしたら、_dataの中はなぜかDoctrine_Null…
なんやねん!もう!!と思ってたら、Validatorをsetしていなかったのが問題でした。

class HogeForm extends BaseHogeForm
{
  public function configure()
  {
    $this->setWidget('hogehoge_name', new sfWidgetFormInputText());
    $this->setWidget('hogehoge_comment', new sfWidgetFormInputText());
    //使う項目の種類とか記述(sfWidgetFormInputText,sfWidgetFormChoiceとか)
    //Baseの項目をオーバーライドする
    
    $this->setValidators(array(
            'hogehoge_name'     => new sfValidatorString(array('max_length' => 30), array(
                'max_length'    => '名前が長すぎるよ小沢さん'
            )),
            //ここでバリデータをセットする。
            'hogehoge_comment'  => new sfValidatorString(array('max_length' => 150, 'required' => false), array(
                'max_length'    => 'コメントが長すぎるよ小沢さん'
            ))
    ));
  }
}
こんな感じ。

くそー、、変なところでハマってしまった。。


詰まってる

こんばんは。ベトナムには日曜の朝8時の便で行ってきます。
帰国は翌週水曜日になるかと。
その日はお休みなので、李君の引越し祝いじゃないけど、おみやげの珈琲でももっておじゃまするかおじゃまされるかしようと思ってるとっくんです。

さてはて、ここ最近既存のプログラムにバグが見つかり改修を進めてるのですが、ちょっと詰まってます。

なぜか

$q = this->findOneByHogeIdAndHugaName($hogeid, $huganame);
として引っ張ってきた物を
$q->setOption($option);
$q->save();
として流してるのだが、コレが一向に改善されない。。
PrimaryがIDではなくhogeidとhuganameという複合主キーとなってるんですが、同じhogeidの別のhuganame、全部が更新されてしまうという。

明日もコレで悩みそうだ。


Symfonyでの項目追加

ふと項目の追加とかページの追加作業を行っている時に、別のタスクを処理してどこまでやってたかを時々忘れてしまうとっくんです。
こんばんは。
今回は項目追加について少しだけ。
そして、びみょーに動作が人によって違うかもしれません。ご了承下さいましー。


今回も完全にSymfony周辺をいじくる覚書です。
とりあえずDBにカラムを追加

ALTER TABLE customers ADD COLUMN hogehoge varchar(255)  AFTER hoge;
//テーブルcustomersのカラムhogeの後に、hogehogeというカラムを追加


そこからコマンドラインでschema.ymlを生成すればOK
symfony doctrine:build-schema
・・・のはずが今日はここでエラーが出た。
SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax;
check the manual that corresponds to your MySQL server version for the right syntax to use near 'order' at line 1.
Failing Query: "DESCRIBE order"
おお・・・?なんぞや?と思ったら「order」って予約語じゃねーかバーロー


予約語に関しては以下の公式リファレンスをご確認ください。

8.3. MySQLでの予約語の扱い
意外にもCONVERTとかはOKだったりする。

此方のページでも予約語についていろいろ書かれてますのでよろしければどうぞ。

MySQLで使ってはいけないワード一覧 – Layer8



一応・・・出来ないことはないけど、後々バグの温床になるのはねげれなので、大人しくテーブル名を変更する。
ALTER TABLE `order` RENAME TO orders;
//シングルクウォートで囲むと予約語をカラム扱いしてくれる
上はあくまで一例ですが、シングルクウォートで囲んでやれば問題なくSQLが通ります。
ほいリネーム完了!そして難なくschemaの生成に成功。


次にDoctrine先生にModel部分を自動生成してもらいましょう。同じくコマンドラインで操作です。
symfony doctrine:build-model
これで見事、MyProject>model>form>doctrine>baseのディレクトリに自動生成されるBaseHuga.classが生成されました。
あとは、それをオーバーライドする子クラスを一つ上の階層MyProject>model>form>doctrineにHuga.Classを作成してやればOKですたい。



ついでにModuleも作成しちゃいましょうかね。コマンドライン操作です。
symfony generate:module frontend huga
これで無事、ほぼまっさらなhugaというページが生成されました。
※正確にはtempletes>indexSuccess.php(View側)とactions>actions.class(Controller)が生成されます。




大体そんな感じ。
ギャグ漫画日和┫・∀・┣
そして改行プラグインいれなめっちゃ見づらいやんけ。