もともと使うものがあったのですが、一日仕事をしていたのでアドリブをしながら、オリー
カートapi実施進捗
検索します.すべては自分で作成しています.誰もapiを書いたことがないので
私たちは考えて、探して実施すべきだと思います.
シャベルとは、無限にシャベルを打つことです.

どうして野菜かごを買いますか。

実は私が作ったページにはカートは必要ありません.
一度に1種類しか決済できないので、最初から単発性に重点を置いて購入する必要はありません.
しかし一般的には、クボンやネイバーで買い物をしている間に買い物かごがない様子は想像できません.
決済検証、返金課題はとっくに終わっていたので、悩んでいました.

ショッピングバスケットは揮発性ですか?

私が考えた最初の構造はこうです.

プレイヤーはアカウントを生成します.

ユーザーは、アカウントを作成すると同時に、本人1:1に縛られたショッピングバスケットテーブルを生成します.

このような基調で編成が始まり・・・調べてみると、ショッピングバスケットは揮発性だそうです.
これは、管理データのすべてが最終的に돈と密接に関連しているためです.
不要なデータは保存しないほうがいいです.
考えてみてください.もし私たちも倉庫に何も入っていなければ、文字列を見せてあげます.

これにより,ショッピングバスケットはユーザが物を詰めた瞬間にテーブルを生成する.
注文または削除テーブルの値が0の場合、
対応するテーブルを削除することは、データセットの処理に役立ちます.
しかもショッピングバスケットもそんなに貴重なシステムではありません.
ユーザーがカートに乗る時間はショッピングモールでもあまり比重を占めず、
買い物かごの中のものを見せるために複雑なものを作る必要はありません.こんな内容も見られました.

では、カートのデータベース構造は?

まず基本動作原理はこのように回転します

プレイヤーは商品をショッピングバスケットに入れるボタンをクリックします.

のプレイヤーIDを含む新しいショッピングバスケットテーブルが作成されます.

ユーザーがクリックした商品データを含む情報を2番テーブルに入れます.

カート表には、次のものが含まれます.
ユーザーを参照できる必要があります.
商品を参照できるようにしてください.
なぜなら.プレイヤーはもちろん参考にしてください.
商品を参照しないと、買い物かごに物が入っていても、中に何が入っているのか分かりません.
私は画面に表現できないと思っていました.
単独招待も一つの方法だが、関係を築くことが望ましい.
次のような形式です.

最上階から
idはカートのidです
createAtはカード作成時間です
items内部には該当商品の情報が含まれています
user内部はカートを所有するユーザのid(OneToOne FK)
構成の仕組み.
検索すると、プレイヤーはいろいろなカートを持つことができます.だから
ユーザーとカートはOneToManyの構造を持っています.こんなコメントも見ました…
ソフトトレードをしないで、テーブル自体を爆破したら、OneToOneでもいいでしょうか?そう思います.
(そうでなければ、交換すればいいのですが、どれくらいかかりますか)

現在作成されているCRU構造

まだ削除していません.
なぜなら...まだ更新に必要なものが実現していないので...ははは….ほほほ

Create

まず私はCreateを持っていません
私はOneToOneなので1つしか生成できません.
私はそれを更新に入れました.こちらのほうが気持ちがいいと思います.
もし問題があれば、分かればいいです.
(これがManyToOneですか?ちょっと待って)

Read

Readもしないでこうすればいい

const Read_User_Data = await this.CartRepository.findOne({
        where: { id: user_cart.id },
        relations: ['items', 'user'],
      });

カートのRepositoryから該当ユーザのカートのIDを取得する.
関連するitems(私は今商品表にいます)は2つのuserを参考にします.
リターンボールだと思います.
実際の操作では、ログインが必要です.@UseGuardsがあるはずです.私はコインにプレイヤーの固有IDを入れたからです.
この構造をコードで実現するといえば、

async read({ currentUser }) {
    const user = this.CartRepository.createQueryBuilder()
      .where({ user: currentUser.user_id })
      .getOne();
      //
      const Read_User_Data = await this.CartRepository.findOne({
        where: { id: user.id },
        relations: ['items', 'user'],
      });
      //
     return Read_User_Date
  }

こんなことになるのかな?考えています.
2人のスタッフになる必要はないと思いますが、ずっと考えていた部分は
私が受け取ったフロントで受け取ったのは、2つのコインの中のプレイヤーidとeamilだけです.
ただし,ユーザ以外のすべてのテーブルはユーザidを関係として参照される.
参照したデータに基づいてすべての値を抽出する方法が分かりません.
上記のコードはカード上のデータのみを受信し、これらのデータは受信した取引ユーザのIDによって署名される.
必要なのは조인이 되어있는 Cart의 데이터를 가져오면서 조인이 되어있는 모든 테이블です.
これは私が思ったほどではなく、私を悩ませた.ブログが有名になると、他の人もたくさん見たり書いたりします.
本当に個人を満足させるために使われているので、誰に聞くべきですか?
しかし、上で使用している>createQuery Builderには確かにいくつかの関係タイプがあり、もう一度探してみる必要があります.
それができれば、私のコードは総じて減ると思います.
(短縮しても人を見るのは難しくない…)

Update

更新は実装中で、コードは非常に複雑です...ゆっくりと注釈をつけて新聞に載せる.

  async update({ updateCartInput }) {
    const { items, ...date } = updateCartInput;
    //
    // 일단 받아오는 값이 items과 유저 아이디라서 구조분해할당으로 쪼개놓는다.
    //
    const PlusCart = await this.itemRepository.findOne({
      where: { id: items[0] },
    });
    //
    // item(상품은 원래 디비에 저장되어있음!)
    // 그것을 기반으로 가져온다. 아이템이 배열의 형식이라서 [0]을 하긴 했는데
    // 한개씩 받아서 추가한다면 굳이 배열의 형식을 써야할까? 그냥 String으로 해도 될 것 같다.
    // 아 동일한 상품이 여러개 들어올 수도 있으니 배열로 해야하나. . . .. ?
    //
    const user_cart = await this.CartRepository.createQueryBuilder()
      .where({ user: date.user_id })
      .getOne();
      // 최상단에서 받아온 유저의 아이디로 조인되어있는 Cart 테이블 검색
      //
    if (!user_cart) {
    //
    // 장바구니가 없을 경우 생성
    //
      const arr = [];
      arr.push(PlusCart);
      console.log('추가');
     //
     // items이 배열의 형식으로 구현이 되어있고 가져온 값들 또한 
     // 배열의 형식이라서 따로 뽑아서 담아주고 있는데 그냥 때려박아도 될 것 같다. 
     //이 부분도 고민을 좀 해봐야한다. 
     //
      const createCart = await this.CartRepository.save({
        user: { user_id: date.user_id },
        name: '10',
        items: arr,
      });
     // name은 참고좀 한다고 넣어놨다. 나중에는 장난감 외 5개 이런식으로 구현이 될 것이다.
     // 나중에는 가격 탭이 들어갈 예정이다, items에서 뽑아온 amount의 총액이 된다.
      return createCart;
     // 프론트로 리턴
    } else {
      // 장바구니가 있을 경우 수량 증가
      // 같은 물품이 들어온다면 금액을 원래 금액 * 2를 하고
      // 수량이라는 데이터를 상품쪽에 달아놓고, +1을 해준다
      const Read_User_Data = await this.CartRepository.findOne({
        where: { id: user_cart.id },
        relations: ['items', 'user'],
      });
      // 카트가 존재한다면 위에서 선언한 것으로 Cart 테이블을 불러온다
      //================================================================
      // @@@@@@구현 중인 내용 @@@@@@@@
      // 뭘 구현하고 있냐면 동일한 물건이 들어왔을 경우
      // 해당하는 물건의 수량을 +1을 해주고 가격 또한 *2를 해주는 작업을 하고 있다.
      // 가급적 병렬처리를 할 수 있도록 map이나 forEach로 작업을 해보려고 하고 있는데
      // 장바구니는 보통 한번에 한개의 물품 혹은 한개의 물품이지만 다량의 수량이 들어오기 때문에
      // 그냥 for문으로 해도 되지 않을까? 라는 생각에 잠겨있다.
      //
      //   Read_User_Data.items.map((ele, idx) =>
      //     ele.id.includes(PlusCart.id) ? console.log('aaaa') : console.log('bbb'),
      //   );
      //
      //   Read_User_Data.items.forEach((ele) => ele.id.includes(PlusCart.id) 
      // ? ele.amount += ele.amount);
      // console.log(Read_User_Data.items[0].id);
      //================================================================
      //
      Read_User_Data.items.push(PlusCart);
      // 위에 카트에 선언되어있는 테이블에 items에 새로 불러온 상품에 대한 정보를 밀어넣는다.
      console.log('업데이트');
      const Update_Cart = await this.CartRepository.save({
        ...Read_User_Data,
      });
      //
      // 상품이 추가적으로 밀려 들어간 것이 Read_User_Data에 담겨있기 때문에
      // 그것을 다시 저장해준 후, 리턴을 해준다.
      return Update_Cart;
      // 여기서도 고민이 조금 있는데, 이대로 보내버리면 유저의 정보 또한 보여진다.
      // 이래서 음....... 그냥 리턴을 안해도 되는 것 같은데 어떻게 해야할지 고민이다.
    }
  }
}

コードのすべての内容に...なんだ.

Delete

最初の問題は削除です.
私はまだ削除に関する正確な知識を持っていないからです.
Typeフォームでサポートされているソフトdeleteを使用します.
テーブル自体の値>は消えません<.
追加のテーブル生成がなければ、本当に1:1の関係を維持します.
交換するので、明日質問するかもしれません.

したがって、カートapiの全体的な構造は

ユーザは、物品を追加すると、すぐにショッピングバスケットテーブルを生成する.

その表にはプレイヤーの情報とアイテムの情報が含まれています.

物品が大量に増加すると、物品の情報が配列された形で積み上げられる構成となっている.

アイテムを削除すると、ショッピングバスケットのアイテム配列では、そのアイテムの情報だけが消えてしまいます.

すべてのものが消えたり、注文したりすると、ショッピングバスケットのテーブルが削除されます.

うん.
削除すると、注文の状況はどのように表示されますか?参考になるものはないでしょう.
..........?
だから本当にManyToOneなの?本当ですか.