EC-CUBE 開発コミュニティ

機能要望 > その他 > 規格まわりの内部構成変更について

その他

投稿者	スレッド
nanasess	投稿日時: 2010/9/27 19:45 対応状況: −−−
神登録日: 2006/9/9 居住地: 投稿: 2313	Re: 規格まわりの内部構成変更について商品一覧画面と商品詳細画面で, product_class_id を取得し, カートの商品を product_class_id で特定するよう修正しました. http://svn.ec-cube.net/open_trac/changeset/18829

nanasess	投稿日時: 2010/9/27 13:57 対応状況: −−−
神登録日: 2006/9/9 居住地: 投稿: 2313	Re: 規格まわりの内部構成変更について引用： ECCUOREさんは書きました：現在、カートに商品が入らないみたいなので /data/class/SC_Product.phpに「getClasscategoryIdsByProductClassId」をいう関数を勝手に追加してしまいました。商品一覧画面と商品詳細画面で、product_class_idが特定できないので、カートに入れる前に、規格カテゴリID1,2をもとに取得してます。ありがとうございます. ちょうど同じような関数を作成していました^^; 商品一覧画面と, 商品詳細画面で, product_class_id を取得できるよう修正中です.

ECCUORE	投稿日時: 2010/9/27 13:35 対応状況: −−−
長老登録日: 2009/10/22 居住地: 東京投稿: 248	Re: 規格まわりの内部構成変更について現在、カートに商品が入らないみたいなので /data/class/SC_Product.phpに「getClasscategoryIdsByProductClassId」をいう関数を勝手に追加してしまいました。商品一覧画面と商品詳細画面で、product_class_idが特定できないので、カートに入れる前に、規格カテゴリID1,2をもとに取得してます。 ---------------- EC CUORE 株式会社クオーレカスタマイズ御相談下さい。

nanasess	投稿日時: 2010/9/27 10:44 対応状況: −−−
神登録日: 2006/9/9 居住地: 投稿: 2313	Re: 規格まわりの内部構成変更について引用： ECCUOREさんは書きました：今後、カートやオーダーテーブルでは、classcategory_id1,classcategory_id2　を使わないで、product_class_id を使うと考えてよろしいでしょうか？はい, その方向で考えています. # 修正が追いついてなくてすみません...

ECCUORE	投稿日時: 2010/9/27 10:31 対応状況: −−−
長老登録日: 2009/10/22 居住地: 東京投稿: 248	Re: 規格まわりの内部構成変更について引用：カートの中の商品なども, classcategory_id1, classcategory_id1 で特定していますが, product_class_id を使用した方が良いと思っています. 今後、カートやオーダーテーブルでは、classcategory_id1,classcategory_id2　を使わないで、product_class_id を使うと考えてよろしいでしょうか？ ---------------- EC CUORE 株式会社クオーレカスタマイズ御相談下さい。

nanasess	投稿日時: 2010/9/22 14:01 対応状況: −−−
神登録日: 2006/9/9 居住地: 投稿: 2313	Re: 規格まわりの内部構成変更について引用：引用： SC_Product getProductsClassByProductIds で　dtb_class_combination　をLEFT JOIN していますので、データが無い場合、LEVELがNULLになり LEVEL判定（getProductsClassFullByProductId）で、商品情報がLOSTしているように見受けられますが、如何でしょうか？規格無しにも対応したつもりだったのですが, version-2_5-dev へマージした際にデグレが発生したかもしれません. ちょっと調べてみます. ありがとうございます. r18820 で修正しました. http://svn.ec-cube.net/open_trac/changeset/18820

seasoft	投稿日時: 2010/9/22 12:20 対応状況: −−−
神登録日: 2008/6/4 居住地: 投稿: 7367	Re: 規格まわりの内部構成変更について ECCUORE 様、nanasess 様なるほど、従来の classcategory_id1, classcategory_id2 は NOT NULL DEFAULT 0 でしたが、 class_combination_id は、NULL DEFAULT NULL なわけですね。とりあえず、現状を把握できました。ありがとうございます。 ---------------- Seasoft こちらでの投稿は、アイディア程度に留めさせていただいております。個別案件の作業は有償で承っております。お気軽にご相談ください。

nanasess	投稿日時: 2010/9/22 11:52 対応状況: −−−
神登録日: 2006/9/9 居住地: 投稿: 2313	Re: 規格まわりの内部構成変更について引用：反面 product_class_id としてキーを用意せずに、複数列 (規格改訂後の場合、product_id, class_combination_id でしょうか?) でキーを組んでも良いのでは、とも思っていました。ユニークを保つ必要がある性質のものだとも思いますし。最初は, 複数キーも考えたのですが, * class_combination_id が NULL になる場合があること * EC-CUBE1.x からの慣習で, あまり複数キーが使われてないことから, product_class_id を流用するようにしました. そもそも, 1.x の頃は主キーという概念が無かったので, product_class_id が使われてなかったのだと思われます. また, ソースのコメントに書いていますが, 現在は dtb_class_combination テーブルを DELETE/INSERT で処理していますが, 本来的には UPDATE の方が良い気がします.

ECCUORE	投稿日時: 2010/9/22 11:52 対応状況: −−−
長老登録日: 2009/10/22 居住地: 東京投稿: 248	Re: 規格まわりの内部構成変更について引用： seasoftさんは書きました：複数列 (規格改訂後の場合、product_id, class_combination_id でしょうか?) でプライマリキーこの件で、少し気になる事があります。現状、class_combination_idがNULLになるケースがあるという事なので、購入後に商品を特定するようなケースでは、product_class_id以外に、小細工せずに一意に特定することができなくなるのではないかと思います。実行SQL： SELECT pc.product_code AS product_code, pc.product_id AS product_id, pc.product_class_id AS product_class_id, pc.class_combination_id AS class_combination_id, cc2.classcategory_id AS classcategory_id1, cc1.classcategory_id AS classcategory_id2 FROM dtb_products_class pc LEFT JOIN dtb_class_combination cc1 ON pc.class_combination_id = cc1.class_combination_id LEFT JOIN dtb_class_combination cc2 ON cc1.parent_class_combination_id = cc2.class_combination_id 結果： +--------------+------------+------------------+----------------------+-------------------+-------------------+ \| product_code \| product_id \| product_class_id \| class_combination_id \| classcategory_id1 \| classcategory_id2 \| +--------------+------------+------------------+----------------------+-------------------+-------------------+ \| ice-01 \| 1 \| 1 \| 10 \| 3 \| 6 \| \| ice-01 \| 1 \| 2 \| 11 \| 3 \| 5 \| \| ice-01 \| 1 \| 3 \| 12 \| 3 \| 4 \| \| ice-01 \| 1 \| 4 \| 13 \| 2 \| 6 \| \| ice-01 \| 1 \| 5 \| 14 \| 2 \| 5 \| \| ice-01 \| 1 \| 6 \| 15 \| 2 \| 4 \| \| ice-01 \| 1 \| 7 \| 16 \| 1 \| 6 \| \| ice-01 \| 1 \| 8 \| 17 \| 1 \| 5 \| \| ice-01 \| 1 \| 9 \| 18 \| 1 \| 4 \| \| nabe-01 \| 2 \| 10 \| NULL \| NULL \| NULL \| +--------------+------------+------------------+----------------------+-------------------+-------------------+ とはいえ、全体的にproduct_class_idをキーにするのは、かなり大がかりな修正になりそうですしね。 ---------------- EC CUORE 株式会社クオーレカスタマイズ御相談下さい。

seasoft	投稿日時: 2010/9/22 11:39 対応状況: −−−
神登録日: 2008/6/4 居住地: 投稿: 7367	Re: 規格まわりの内部構成変更について改訂後の規格については、まだ十分に把握できていませんが、product_class_id の扱いについては、前々から気になっていた部分でして、横から失礼いたします。私も、product_class_id がキーとして使われていない事は気になっていました。反面 product_class_id としてキーを用意せずに、複数列 (規格改訂後の場合、product_id, class_combination_id でしょうか?) でプライマリキーを組んでも良いのでは、とも思っていました。ユニークを保つ必要がある性質のものだとも思いますし。 ---------------- Seasoft こちらでの投稿は、アイディア程度に留めさせていただいております。個別案件の作業は有償で承っております。お気軽にご相談ください。

(1) 2 3 »