From www.remix.gr.jp ＠ gmail.com Thu Aug 13 08:55:40 2009 From: www.remix.gr.jp ＠ gmail.com (http://www.remix.gr.jp/) Date: Thu, 13 Aug 2009 08:55:40 +0900 Subject: [ethna-users:1159] =?iso-2022-jp?b?RXRobmEtMi41LjAtcHJldmlldzUgGyRCJEc6Rjg9JDkbKEI=?= =?iso-2022-jp?b?GyRCJGskNEpzOXAkRyQ5ISMbKEI=?= Message-ID: <001701ca1ba8$66e5eac0$0a00a8c0@FM635116487> 　原因などを追いきれておりませんのでバグなのか定かではありませんが過去に同様なエラーに関する投稿が見当たりませんでしたのでご報告させていただきます。　Ethna-2.5.0-preview5 で、'log_level' => 'debug' とし、ビューの preforward() 先頭で Ethna::raiseNotice()、Ethna::raiseWarning()、Ethna::raiseError() などを呼び出しますと、Ethna_Plugin_Logwriter::_getBacktrace() の debug_backtrace() で Notice: Undefined index: file in /webapp/APPID/lib/Ethna/class/Plugin/Logwriter.php on line 195 Notice: Undefined index: line in /webapp/APPID/lib/Ethna/class/Plugin/Logwriter.php on line 202 が出力されます。　Ethna-2.5.0-preview3 にダウングレードすれば出なくなることが分かっております。再現環境　Ethna-2.5.0-preview5. 　Smarty Version 2.6.26 　PHP Version 5.1.6 　CentOS release 4.6 (Final) http://www.remix.gr.jp/service/blog/2009/08/ethna250preview5.html From takaoka ＠ beatcraft.com Thu Aug 13 10:28:35 2009 From: takaoka ＠ beatcraft.com (Yoshinari Takaoka) Date: Thu, 13 Aug 2009 10:28:35 +0900 Subject: [ethna-users:1160] Re: =?iso-2022-jp?b?RXRobmEtMi41LjAtcHJldmlldzUgGyRCJEc6Rjg9GyhC?= =?iso-2022-jp?b?GyRCJDkkayQ0SnM5cCRHJDkhIxsoQg==?= In-Reply-To: <001701ca1ba8$66e5eac0$0a00a8c0@FM635116487> References: <001701ca1ba8$66e5eac0$0a00a8c0@FM635116487> Message-ID: <59ea035f0908121828obc35c30rdfb00fdd27ec6d0e@mail.gmail.com> 高岡です。 2009/8/13 http://www.remix.gr.jp/ : > 　原因などを追いきれておりませんのでバグなのか定かではありませんが > 過去に同様なエラーに関する投稿が見当たりませんでしたのでご報告させていただきます。 > > Ethna-2.5.0-preview5 で、'log_level' => 'debug' とし、ビューの preforward() 先頭で > > Ethna::raiseNotice()、Ethna::raiseWarning()、Ethna::raiseError() > > などを呼び出しますと、Ethna_Plugin_Logwriter::_getBacktrace() の debug_backtrace() で > > Notice: Undefined index: file in /webapp/APPID/lib/Ethna/class/Plugin/Logwriter.php on line 195 > Notice: Undefined index: line in /webapp/APPID/lib/Ethna/class/Plugin/Logwriter.php on line 202 > > が出力されます。 > Ethna-2.5.0-preview3 にダウングレードすれば出なくなることが分かっております。御報告ありがとうございます。 git の最新版でも再現しましたので、調査させてください。チケットにも登録しておきました。 http://sourceforge.jp/ticket/browse.php?group_id=1343&tid=18201 どうぞ宜しくお願い致します。 -- Yoshinari Takaoka takaoka ＠ beatcraft.com From takaoka ＠ beatcraft.com Thu Aug 13 11:15:42 2009 From: takaoka ＠ beatcraft.com (Yoshinari Takaoka) Date: Thu, 13 Aug 2009 11:15:42 +0900 Subject: [ethna-users:1161] Re: =?iso-2022-jp?b?RXRobmEtMi41LjAtcHJldmlldzUgGyRCJEc6Rjg9GyhC?= =?iso-2022-jp?b?GyRCJDkkayQ0SnM5cCRHJDkhIxsoQg==?= In-Reply-To: <59ea035f0908121828obc35c30rdfb00fdd27ec6d0e@mail.gmail.com> References: <001701ca1ba8$66e5eac0$0a00a8c0@FM635116487> <59ea035f0908121828obc35c30rdfb00fdd27ec6d0e@mail.gmail.com> Message-ID: <59ea035f0908121915r94cea21mf8284e6854d86a2a@mail.gmail.com> 高岡です。 2009/8/13 Yoshinari Takaoka : > 御報告ありがとうございます。 > git の最新版でも再現しましたので、調査させてください。 > > チケットにも登録しておきました。 > http://sourceforge.jp/ticket/browse.php?group_id=1343&tid=18201 上記を修正しました。宜しければ以下のpatchをお試し下さい。 http://git.sourceforge.jp/view?p=ethna/ethna.git;a=commitdiff;h=8a67056d830deff738548b6f42957b4847b09481#patch2 御報告ありがとうございました。 -- Yoshinari Takaoka takaoka ＠ beatcraft.com From hashibata ＠ gmail.com Sat Aug 15 21:00:09 2009 From: hashibata ＠ gmail.com (Hiroshi Hashibata) Date: Sat, 15 Aug 2009 21:00:09 +0900 Subject: [ethna-users:1162] =?iso-2022-jp?b?TWFuYWdlchskQiROSiwzZCRyJDckRiQkJF4kOSQrISkbKEI=?= Message-ID: <39f7d3b80908150500i7c55cb7et3a517ed1b097f091@mail.gmail.com> こんにちは EthnaのManagerを、だいたい１テーブルに１つ対応させて作ってます。ですがSELECT文のバリエーションごとにメソッドを１つ作っているので、最近は数が多くなってきました。たとえばこんな感じに function A() { $sql = "SELECT id, name FROM table1 } function B() { $sql = "SELECT MAX(id) FROM table1 } ... SQLが複雑だとSQLを作るプライベートメソッドもあります。 Managerを編集しようとしてスクロールしてると「うわ、多いなー」って感じなのですがみなさんならどうやって解決しますか？ Hiroshi Hashibata From mumumu ＠ mumumu.org Wed Aug 19 12:23:12 2009 From: mumumu ＠ mumumu.org (Yoshinari Takaoka) Date: Wed, 19 Aug 2009 12:23:12 +0900 Subject: [ethna-users:1163] Re: =?iso-2022-jp?b?TWFuYWdlchskQiROSiwzZCRyJDckRiQkJF4kOSQrGyhC?= =?iso-2022-jp?b?GyRCISkbKEI=?= In-Reply-To: <39f7d3b80908150500i7c55cb7et3a517ed1b097f091@mail.gmail.com> References: <39f7d3b80908150500i7c55cb7et3a517ed1b097f091@mail.gmail.com> Message-ID: <20090819122312.92456626.mumumu@mumumu.org> 高岡です。こんにちは。お返事が遅くなってすみません。 On Sat, 15 Aug 2009 21:00:09 +0900 Hiroshi Hashibata wrote: > EthnaのManagerを、だいたい１テーブルに１つ対応させて作ってます。 > ですがSELECT文のバリエーションごとに > メソッドを１つ作っているので、最近は数が多くなってきました。 > たとえばこんな感じに > > function A() { > $sql = "SELECT id, name FROM table1 > } > > function B() { > $sql = "SELECT MAX(id) FROM table1 > } > > ... SQLが複雑だとSQLを作るプライベートメソッドもあります。 > > Managerを編集しようとしてスクロールしてると > 「うわ、多いなー」って感じなのですが > みなさんならどうやって解決しますか？僕は上記のようなManagerの使い方はしたことがないのですが 1. 別クラスを作り、継承または委譲させる 2. SQLを組み立てるメソッドが多いのなら、別クラスに追い出して委譲させるということは最低限考えると思います。ただ、1テーブル 1クラス（1ファイル）であるなら、ファイルは分割しないかもしれません。＃僕はAppObjectとManagerが強く結びついたクラスとみて使った＃ことがありません。2.3.x 系までは、Managerのスケルトンが＃AppObjectのそれと一体になっていることに加え、ヘルパも用意＃されており、結びつきがそれなりに強く作られていますが、2.5.0 ＃ではそれをいくぶん緩める予定ですどうぞ宜しくお願いします。 -- Yoshinari Takaoka (mumumu ＠ IRC) reversethis -> gro tod umumum ta umumum From hashibata ＠ gmail.com Thu Aug 20 00:18:20 2009 From: hashibata ＠ gmail.com (Hiroshi Hashibata) Date: Thu, 20 Aug 2009 00:18:20 +0900 Subject: [ethna-users:1164] Re: =?iso-2022-jp?b?TWFuYWdlchskQiROSiwzZCRyJDckRiQkJF4kOSQrGyhC?= =?iso-2022-jp?b?GyRCISkbKEI=?= In-Reply-To: <20090819122312.92456626.mumumu@mumumu.org> References: <39f7d3b80908150500i7c55cb7et3a517ed1b097f091@mail.gmail.com> <20090819122312.92456626.mumumu@mumumu.org> Message-ID: <39f7d3b80908190818x577ae2ao286305813e3fdcd1@mail.gmail.com> 橋端です。こんにちは。ご提案をいただきました。ありがとうございます。今回は設計をよく見直し、思い切って別クラスも作り、そこに処理を委譲することで軽量化を計っていきます。ところでEthnaを使い始めた頃、公式ページのドキュメントとＬＬフレームワークの本を見ました。これらには簡単なサンプルが書かれていましたが、それではすぐに行き詰まりを感じるようになりました。 EthnaのAppObjectは単一テーブルしか扱えないと書かれていてですが実務では複数のテーブルを結合することがほとんどです。それなら素のSQLを書けばいいじゃないか、ということになり、 Managerとはそう使うんじゃないか、という推測から現在の形になっています。だから他の人たちはどうしていんだろうと、いつも気になっています。単純なログインフォームのチュートリアルではなくて自分たちが書いているコードとはまた違った、別な実務的なコードやTipsとふれあいたいと思っています。そのためにどうすればいいのか模索中です。 Hiroshi Hashibata From www.remix.gr.jp ＠ gmail.com Thu Aug 20 08:35:08 2009 From: www.remix.gr.jp ＠ gmail.com (http://www.remix.gr.jp/) Date: Thu, 20 Aug 2009 08:35:08 +0900 Subject: [ethna-users:1165] Re: =?iso-2022-jp?b?RXRobmEtMi41LjAtcHJldmlldzUgGyRCJEc6Rjg9GyhC?= =?iso-2022-jp?b?GyRCJDkkayQ0SnM5cCRHJDkhIxsoQg==?= References: <001701ca1ba8$66e5eac0$0a00a8c0@FM635116487><59ea035f0908121828obc35c30rdfb00fdd27ec6d0e@mail.gmail.com> <59ea035f0908121915r94cea21mf8284e6854d86a2a@mail.gmail.com> Message-ID: <000c01ca2125$b24540b0$0a00a8c0@FM635116487> パッチの適用で改善することを確認できております。ありがとうございました。ＰＳ．こちらのご回答への返信方法が分からず（恥ずかしい・・・）、 Outlook Express の返信で Subject の先頭に付加される Re: [ethna-users:1161] で判別されるのかなと勝手に推測しましたが、新しいスレッドになっていたらスミマセン。 From www.remix.gr.jp ＠ gmail.com Thu Aug 20 10:00:29 2009 From: www.remix.gr.jp ＠ gmail.com (http://www.remix.gr.jp/) Date: Thu, 20 Aug 2009 10:00:29 +0900 Subject: [ethna-users:1166] Re: =?iso-2022-jp?b?TWFuYWdlchskQiROSiwzZCRyJDckRiQkJF4kOSQrGyhC?= =?iso-2022-jp?b?GyRCISkbKEI=?= References: <39f7d3b80908150500i7c55cb7et3a517ed1b097f091@mail.gmail.com><20090819122312.92456626.mumumu@mumumu.org> <39f7d3b80908190818x577ae2ao286305813e3fdcd1@mail.gmail.com> Message-ID: <000501ca2131$9e7c2290$0a00a8c0@FM635116487> 　私の場合、 > function A() { のような集合を取得するケースはテーブル毎にAPPID_Table1Managerで function &A( $select=null, $where=null, $order=null, $offset=null, $limit=null ){ unset( $row ); $row = $this->getObjectPropList( 'table1' , $select , $where , $order , $offset , $limit ); return $row; } で統一し固有の要件別にラッパーを追加して使っています。例：http://www.remix.gr.jp/service/blog/2009/03/ethna_getobjectproplist_3.html 頻繁に使うwhere句 Ethna_AppSearchObject() もテーブル毎にAPPID_Table1Managerに配置しています。　呼び元がパラメータ・例外・JOIN・トランザクションを意識するつくりです。　APPID_Table1 extends Ethna_AppObject には十分に相手を吟味して必要ならJOIN条件を記述しています。参：http://www.remix.gr.jp/service/blog/2008/11/ethna_mysql_join.html > function B() { のようなケースは、SQLのVIEWにして、ethna からは別のテーブルとして扱っています（程度にもよりますが）。　生SQLを記述しないつくりを意識していますが、高速に複数レコードを更新する場合などはテーブル毎のAPPID_Table1Managerに生SQLを記述してます。　まだ、クラスにまとめあげるレベルに達していないので参考にはならないかもしれません。読み流してくださいませ。 From hashibata ＠ gmail.com Thu Aug 20 14:35:26 2009 From: hashibata ＠ gmail.com (Hiroshi Hashibata) Date: Thu, 20 Aug 2009 14:35:26 +0900 Subject: [ethna-users:1167] Re: =?iso-2022-jp?b?TWFuYWdlchskQiROSiwzZCRyJDckRiQkJF4kOSQrGyhC?= =?iso-2022-jp?b?GyRCISkbKEI=?= In-Reply-To: <000501ca2131$9e7c2290$0a00a8c0@FM635116487> References: <39f7d3b80908150500i7c55cb7et3a517ed1b097f091@mail.gmail.com> <20090819122312.92456626.mumumu@mumumu.org> <39f7d3b80908190818x577ae2ao286305813e3fdcd1@mail.gmail.com> <000501ca2131$9e7c2290$0a00a8c0@FM635116487> Message-ID: <39f7d3b80908192235n63f1b83dy2464a2b485ef39ee@mail.gmail.com> ありがとうございます。そうですね。勉強になります。 MAX(id)をVIEWを使ってtableとしても、パターンごとに１クラスを作るのは大変ですね。一部はSQLをそのまま記述するなどケースバイケースで柔軟に対応するようにします。 Hiroshi Hashibata From itoh ＠ tohokuaiki.jp Fri Aug 21 19:17:33 2009 From: itoh ＠ tohokuaiki.jp (ITOH Takashi) Date: Fri, 21 Aug 2009 19:17:33 +0900 Subject: [ethna-users:1168] Re: =?iso-2022-jp?b?TWFuYWdlchskQiROSiwzZCRyJDckRiQkJF4kOSQrGyhC?= =?iso-2022-jp?b?GyRCISkbKEI=?= In-Reply-To: <20090819122312.92456626.mumumu@mumumu.org> References: <39f7d3b80908150500i7c55cb7et3a517ed1b097f091@mail.gmail.com> <20090819122312.92456626.mumumu@mumumu.org> Message-ID: <4A8E743D.7070404@tohokuaiki.jp> 伊藤です。 Yoshinari Takaoka さんは書きました: > 僕は上記のようなManagerの使い方はしたことがないのですが > > 1. 別クラスを作り、継承または委譲させる > 2. SQLを組み立てるメソッドが多いのなら、別クラスに > 追い出して委譲させる > > ということは最低限考えると思います。ただ、1テーブル > 1クラス（1ファイル）であるなら、ファイルは分割しない > かもしれません。 > > ＃僕はAppObjectとManagerが強く結びついたクラスとみて使った > ＃ことがありません。2.3.x 系までは、Managerのスケルトンが > ＃AppObjectのそれと一体になっていることに加え、ヘルパも用意 > ＃されており、結びつきがそれなりに強く作られていますが、2.5.0 > ＃ではそれをいくぶん緩める予定です私はAppObjectとAppManagerが1つのファイルにあることもあって、意識的には強い結びつきで認識しています（なので、ファイル分割もしたことありません）が、コード的にはそうではないよなぁと思っています。それを一番感じるのが、getObject(Prop)?Listで第一引数に$classを持ってきているところです。AppManagerを指定している以上、これを指定しているのは変だなぁと感じてます。（結びつきが弱いという前提ならなるほどと思います）伊藤 From itoh ＠ tohokuaiki.jp Fri Aug 21 19:17:34 2009 From: itoh ＠ tohokuaiki.jp (ITOH Takashi) Date: Fri, 21 Aug 2009 19:17:34 +0900 Subject: [ethna-users:1169] Re: =?iso-2022-jp?b?TWFuYWdlchskQiROSiwzZCRyJDckRiQkJF4kOSQrGyhC?= =?iso-2022-jp?b?GyRCISkbKEI=?= In-Reply-To: <39f7d3b80908190818x577ae2ao286305813e3fdcd1@mail.gmail.com> References: <39f7d3b80908150500i7c55cb7et3a517ed1b097f091@mail.gmail.com> <20090819122312.92456626.mumumu@mumumu.org> <39f7d3b80908190818x577ae2ao286305813e3fdcd1@mail.gmail.com> Message-ID: <4A8E743E.8080503@tohokuaiki.jp> 伊藤です。 Hiroshi Hashibata さんは書きました: > ところでEthnaを使い始めた頃、公式ページのドキュメントと > ＬＬフレームワークの本を見ました。 > これらには簡単なサンプルが書かれていましたが、 > それではすぐに行き詰まりを感じるようになりました。 > EthnaのAppObjectは単一テーブルしか扱えないと書かれていて > ですが実務では複数のテーブルを結合することがほとんどです。 AppObjectは、0.2時代からずっと複数テーブルの結合を扱えます。 (一応. ダサいけど)コメントにも書いてあるとおりあんまり使い勝手が良いとは言えないんですが。 _SQLPlugin_SearchPropDef() _SQLPlugin_SearchTable() を使います。詳しい使い方とかはこのメソッド名で検索すると何件かあります。ただ、これ、引数無いですし、事実上1つの結合定義しか使えません。それはそれで一時期その束縛感に燃えて使ってたのですが、最近はSQLでJOINさせるより取得したListをforeachで回して何度も SQL発行してます。後でメンテしにくくなるので。なので、リレーション用のテーブルがあるときはそのAppManagerが大活躍したりします。あんまり活躍しすぎると、「JOINつかえばいいじゃん」とか自問してしまいますが。私の場合は使用シーン的に高いパフォーマンスを求められることがほとんどない（代わりに早く作る）というのも理由にありますが。 > それなら素のSQLを書けばいいじゃないか、ということになり、 > Managerとはそう使うんじゃないか、という推測から現在の形になっています。私は素のSQLはあんまり使いません。SQL書くより $filter = array('foo' => new Ethna_AppSearch... とやった方が速いので。 [ethna-users:1166]でも書かれていましたが、まとめてUPDATEとかDELETE 掛けるときはさすがに使いますが、そのケースくらいです。伊藤 From hashibata ＠ gmail.com Sat Aug 22 12:52:04 2009 From: hashibata ＠ gmail.com (Hiroshi Hashibata) Date: Sat, 22 Aug 2009 12:52:04 +0900 Subject: [ethna-users:1170] Re: =?iso-2022-jp?b?TWFuYWdlchskQiROSiwzZCRyJDckRiQkJF4kOSQrGyhC?= =?iso-2022-jp?b?GyRCISkbKEI=?= In-Reply-To: <4A8E743E.8080503@tohokuaiki.jp> References: <39f7d3b80908150500i7c55cb7et3a517ed1b097f091@mail.gmail.com> <20090819122312.92456626.mumumu@mumumu.org> <39f7d3b80908190818x577ae2ao286305813e3fdcd1@mail.gmail.com> <4A8E743E.8080503@tohokuaiki.jp> Message-ID: <39f7d3b80908212052w11e94624n2768a579a916bb1c@mail.gmail.com> 橋端です。 ITOH Takashi さんは書きました: >最近はSQLでJOINさせるより取得したListをforeachで回して何度も >SQL発行してます。後でメンテしにくくなるので。社員名(1)　×　お子さんの名前(0..*)　という関係を10件ずつ表示する（ただし表示するのはお子さんのいる社員だけ表示する）こういう場合に最初に社員を10件取得してループさせると、全員お子さんのいない社員の場合もあります。この場合、出力は0件になります。最初に10件取得したのが間違いで、実際はN件取得しないといけないので社員を全員取得することにします。社員数分、ループさせお子さんのいる社員が10件になったところでループを脱出する、とすることで SQLの等価結合の結果と同じ結果とすることができます。伊藤さんにご提案いただいたロジックだとこういう感じでしょうか？橋端