PostgreSQL の場合、ビューの差異を埋める必要があると思います。

たしか、過去スレで、EC-CUBEコミュニティ(eccube-comu) のビューを持ってきて、コミュニティ固有のカラムを除外して移植された方がいらっしゃったと記憶しています。

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

こんにちは、ec-cube 2.1.2にて、複数カテゴリでの商品並び替えの不具合を修正すべく、チェンジセット17853、17938と適用し、並び替えは正常に動作するようになりましたが、17959を適用した時点で、カテゴリ表示、検索結果画面等に以下のシステムエラーが起きます。

SELECT DISTINCT product_id FROM vw_products_allclass AS allcls WHERE del_flg = 0 AND status = 1 AND category_id IN ( ? )
DB Error: no such field

SELECT DISTINCT product_id FROM vw_products_allclass AS allcls WHERE del_flg = 0 AND status = 1 AND category_id IN ( 4 ) [DB Error: no such field]

バージョン違いによるデータベース差異があるためとは思いますが、ひとまず手動で修正するためにはどのようにしたらよいでしょうか。
どうかご教授下さい。

EC-CUBEバージョン 2.1.2
PHPバージョン PHP 5.2.5
DBバージョン PostgreSQL 8.2.4

梶原様

お世話になっております。
改めてチェンジセット17983を適用させて頂きました。

結果、複数カテゴリに属している商品でも、正常にマイページで１つのみ表示されていました。
加えて、ページ送りも正常に機能しています。
表示件数の上限リミットが解除されたようですね。　（20件以上登録できました。）
--------------------------------------------------------------------------------
※顧客＆お気に入り登録利用数の増加に伴い、ゆくゆくは「最大 ｎ 件まで表示」というように、
管理ユーザー権限で登録上限設定などできれば理想的ですね。
--------------------------------------------------------------------------------

ありがとうございました。
これからも、どうぞ宜しくお願い致します。

株式会社ロックオンの梶原です。

早速のご報告ありがとうございます。＞Linux-user様

お恥ずかしながら、ページ送り部分の処理を見過ごしておりました。
チェンジセット17980のようなSQL処理の方法では、テンプレートのページ送り処理に反映できませんので、SQL処理部分を修正させていただきました。

また、テンプレートにて（※最大20件まで表示）というような文言がありますが、そのように制限するような処理は含まれてないよう見受けられますので、テンプレートの該当文言を削除させていただきました。

詳細は以下チケットもしくは以下チェンジセットをご覧ください。
http://svn.ec-cube.net/open_trac/ticket/441
（最新のLC_Page_Mypage_Favorite.phpを添付しておりますので、よろしければご活用ください。）
http://svn.ec-cube.net/open_trac/changeset/17983

それでは、ご確認のほどよろしくお願いします。

早速、チェンジセット17980を適用させて頂きました。
結果、複数カテゴリに属している商品でも、正常にマイページで１つのみ表示されていました。

ただ、今度は、「次へ」や2ページ目をクリックしても同じものが表示されてしまいます。


実例：マイページ＞お気に入り商品一覧より　　↓↓↓引用：
※この状態で、1ページ目に14件全て表示されています。
「次へ」や2ページ目をクリックしても、同じ14件が表示されています。

以前のように、10個目で折り返し・・という挙動ではないようです。



ひとまずは　「/data/Smarty/templates/default/mypage/favorite.tpl」　より　　↓↓↓引用：
この部分を削除して利用させて頂いております。
※現状でも、上記部分を削除しての利用でしたら、差し当たりの支障はないのですが、
もし、折り返しができるようでしたら、ご教授の程、宜しくお願い致します。



追記：
もし、折り返し実装に、より大幅な改変が必要になります場合は、
（動作上、支障はないようですので）上記ソースを削除して、そのまま利用させて頂きます。

大変すばらしい機能ですね。

株式会社ロックオンの梶原です。

本件ですが、検討の結果、とりあえずビューを使用しないよう修正し、一旦コミットさせていただきました。
http://svn.ec-cube.net/open_trac/changeset/17980

今回のお気に入り機能の一覧を取得する部分は、意外と今までにはあまりない商品情報一覧の取り方となっており、既存のビューを使用した場合、どうしても不完全、もしくは無駄なSQLとなってしまいます。

ですので、一旦、必要な情報のみを取得できるSQLとさせていただきました。
（ビューの名前とmain_list_imageが取得できないのを置いておいたとすれば、SQL的にはvw_products_allclass_detailとお気に入りのテーブルをつなげるのが最も近い形だとは思います。）

また、ご確認いただけましたら幸いです。

今後、（2.4.0では難しいですが）ビューの使用方法や各処理のSQL、ソースなどを見直してスリム化していきたいですね。
ただ、ビューは全体に関わるところなので、少し気を使う修正になる可能性が高いと思っています。
今まで、EC-CUBEは肥大化の一途をたどってきてますが、アプリ自体がそれなりに成熟してきたことと、ご協力いただける開発者の方々もかなり増えてきたことなどにより、ようやくスリム化にも着手できそうです。
ありがたいことです。


毎度、ありがとうございます。
分かり辛いですね、今のマイルストーンと情報の公開方法では。
2.4.1は確実に出すと思いますが、そちらの方向性が決まった段階で、方向性を公表し、マイルストーンも置きますので、今しばらくお待ちくださいませ！

株式会社ロックオンの梶原です。
引用：
MySQLで動作確認しておりましたが、postgresでは確かにエラーになるようですね。
では、このやり方では全く駄目ですね。。。
ご指摘ありがとうございます！！
もう少し検討してみます。

引用：
いえいえ。
オープンソースですので、全員で開発、全員でテストが基本です。
参加していただくことに意義があると思います。
ご報告いただくだけでも全く問題ありません！！

ちなみに、今回は（お気に入り機能ということもあり）パフォーマンスのことはそれほど意識せず、一案として記載させていただきました。
こちらを一案としてより良い改修案にまとまれば幸いと思いまして。
ただ、一覧としてvw_products_allclassを使用するという使用意図としてはそれなりに分かるので、そこはそれほど問題視していませんでしたが、カテゴリ情報を読み込んでるのは確かにパフォーマンス的にはあまりよくないかもしれませんね。
一覧のDISTINCTしているところまで話が広がるとは思っていませんでしたが(^_^;

どのビューを使用するか、もしくはビューを使用しないかあたり、もう少し検討要です。

お気に入り機能はEC-CUBEでは久々の、フロント側の機能追加でして、今回是非入れたいと思っています。
より良い改修案に落とし込みできればと思います！！

引用：
VIEW を使うかというよりも、その VIEW を副問い合わせとみなして展開した SQL文(まさに MySQL 用のロジックが中間生成するSQL文がまさにそれです)が、適切な SQL かという観点が重要かと思います。

で、今回の vw_products_allclass は dtb_product_categories を結合していますが、その処理は必要ない気がします。(未検証)

必要ないテーブルを結合して、展開されたレコードを GROUP BY するというのは、全く無意味な処理だと思います。

そう考えると、結果的に本件の場合は「一般的なやり方」ではない気がしますね。

後発の ONE/DEPO なんかは、その辺りは相当気を使っているようです。「10万点の環境下で平均表示速度1秒〜3秒程」というのは、無駄の無い処理を心がけた賜物だと思います。(EC-CUBE みたいに高度な規格(ONE/DEPO では構成情報と呼びます)が無いという差もありますが)

引用：
規格の使用時に、価格の範囲表示(MIN〜MAX)があるので、少々厳しいかも。

あの生成ロジックが、分散してしまうのも嫌だなぁ・・・

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

引用：
そもそも、商品一覧表示で vw_products_allclass を使っていること自体も、結構怪しい感じがしています。

経験則的に、大量のカラムを DISTINCT している場合、意図しない(すべきでない)プロダクト・ジョインを小手先で誤魔化している場合がほとんどです。パフォーマンス低下にも直結します。

2.4 は久しぶりの大規模な改訂なのですから、むしろ商品一覧も改善していく方向の方が良い気はします。

体力的に厳しいのであれば、小手先で誤魔化したコードを混入させるよりは、当該機能の取り込みを見送り、マイルストーンを置き直すほうが良い気がします。

そういった面からも、マイルストーンは 2.x.x などではなく、2.4.1、2.5.0 などと、誰でも分かるようにすべきかとも思います。

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

確かpostgresSQLだと、group byの所でselectしてくるカラム全部を書かないといけなかったと思います。

viewをgroupってあまりやった事ないのですが、一般的なやり方なんでしょうか？

在庫とか気にしないでdtb_customer_favorite_products inner join dtb_productsしたくなってきました。

引用：
僕も実装しながら思ってたんですが、正式版ではmain_list_imageは必須なので発生しないかな？と思ってやっちゃいました、基本あまりソースを変えたくないので・・・

----------------
EC-CUBEカスタマイズ相談してください。
緊急のEC-CUBEの障害対応
EC-CUBEカスタマイズブログ