Feathers: 必要な多対多の関係文書を作成/更新する

カイル-それはこのように解決しますか？ （例）

ありがとうございました、

マーク・エドワーズ

3時44分PMの木、2018年4月5日には、カイル・コープランド[email protected]
書きました：

こんにちは、

私は現在、私たちのチームのためにフェザーを評価していて、それが大好きです。 私はしようとしています
私たちのすべてのユースケースをカバーし、作成または作成を処理する方法に困惑しています
多対多の関係を持つエンティティ間の関連付けを更新します。

mからnのリレーションシップフェザーの保存と更新をリクエストしたい
例。

シナリオ：
/ playersと/ teamsの2つのサービスがあります（これらは任意のリソースです）
私は考えました）。 プレーヤーは多くのチームに属している可能性があり、チームには多くのチームがあります
プレイヤー。 プレーヤーとチームの関連付けを処理する方法がわかりません
エレガントなファッション。

次の方法を理解したいのですが。

• チームにプレーヤーを追加する
• チームからプレーヤーを削除する

私は関連付けをうまく設定することができます：
team.model.js

..。
team.associate = function（models）{
team.belongsToMany（models.player、{through： 'PlayerTeam'}）;
};
..。

player.model.js

..。
player.associate = function（models）{
player.belongsToMany（models.team、{through： 'PlayerTeam'}）;
};
..。

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/feathersjs/feathers/issues/852 、またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ACyd4jo95mdpY5gNYF3GtdghdDwfwG4Uks5tlp40gaJpZM4TJRE4
。

@edwardsmarkfマークさん、お

こんにちはカイル-画像はこ​​こから来ました：
https://en.wikipedia.org/wiki/Many-to-many_（data_model）-多分
githubメールは写真を許可していませんか？

私はあなたを正しく理解したと思います。

ありがとうございました、

マーク・エドワーズ

5時51分PMに木、2018年4月5日には、カイル・コープランド[email protected]
書きました：

@edwardsmarkf https://github.com/edwardsmarkfねえマーク、ありがとう
手を差し伸べる。 あなたの例は省略されているかもしれないと思います。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/feathersjs/feathers/issues/852#issuecomment-379118164 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ACyd4gMY3kJiprvR3I2fRZP7LThfbvLHks5tlrwDgaJpZM4TJRE4
。

言及するのを忘れた：

https://en.wikipedia.org/wiki/Many-to-many_（data_model ）：

著者と本の多対多の関係を1対多のペアとして
ジャンクションテーブルとの関係

あなたの関係はそれらの間の「ジャンクションテーブル」を得ることができますか？ ジャンクション
テーブルはコメントや日付などを考えただけで保持できるかもしれません。

ありがとうございました、

マーク・エドワーズ

2018年4月5日木曜日午後6時4分、Mark

>>

こんにちはカイル-画像はこ​​こから来ました： https ：
/ Many-to-many_（data_model）-おそらくgithubメールでは許可されていません
写真？

私はあなたを正しく理解したと思います。

ありがとうございました、

マーク・エドワーズ

5時51分PMに木、2018年4月5日には、カイル・コープランド[email protected]
書きました：

@edwardsmarkf https://github.com/edwardsmarkfねえマーク、ありがとう
手を差し伸べる。 あなたの例は省略されているかもしれないと思います。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/feathersjs/feathers/issues/852#issuecomment-379118164 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ACyd4gMY3kJiprvR3I2fRZP7LThfbvLHks5tlrwDgaJpZM4TJRE4
。

ちょっとエドワード、ありがとう。 ORM /フェザーを使用したジャンクションテーブルの処理が当面の問題です。

これが私の最善の推測とSequelizeの問題を解決する方法です。 みなさんのご意見をお聞かせください。

app.use('/team/:teamId/player/:playerId', {
    // Gives the ability to add the association
    create(data, params) {
      return app.service('team').Model.findById(params.route.teamId).then(team => {
        return app.service('player').Model.findById(params.route.playerId).then(player => {
          return team.addPlayer(player);
        });
      });
    },

    // Gives the ability to delete an association
    remove(id, params) {
      return app.service('team').Model.findById(params.route.teamId).then(team => {
        return app.service('player').Model.findById(params.route.playerId).then(player => {
          return team.removePlayer(player);
        });
      });
    }
  });

これはhttps://sequelize.slack.comでもっとよく答えられるのだろうか？ または代わりにビューを使用しますか？

何が最善だと判断したかについて、私に知らせてください。 それは非常に興味深い問題です。

あなたが提案しているそのサービスは実際にはかなりきちんとしています。 また、結合テーブルモデル用に別のサービスを作成することもあります。 @DesignByOnyxは、彼の旅行からここに何か洞察を持っているのだろうか。

新しい関連エントリの作成は、配列をcreate渡すことで機能するはずですが、正しいですか？

みなさんからの返信ありがとうございます。 @dafflの提案ですが、チームプレーヤーのサービスを利用して、フックを介してエントリを結合することになりますか？ また、配列を介して新しい関連エントリを作成することの意味を説明してもらえますか？

ここの@dafflは、サービス対ORMでの私の最良の推測です

サービス指向の方法：

//AFTER HOOK: pseudo-code I haven't tested this

const {result, app} = context;

result.map(async team => {
  const players = await app.service('team-player').find({
      query: {
        teamId: team.id
      }
    }).then(results => {
       return app.service('player').find({
          query: {
            playerId: results.playerId
        });
    });

  team.players = players;
})

return context;

ORMの方法：
`` `
//フック前：これは機能します
context.params.sequelize = {
含む： [ {
モデル：context.app.service（ 'player'）。Model、
として： 'プレーヤー'、
属性：['名前']、
使って： {
属性：[]
}
}]、
生：false
};

コンテキストを返します。

カイル-私はあなたが直面しているのと同じ問題に遭遇しようとしているので、お願いします
これがどのように機能するかを教えてください。

ありがとうございました、

マーク・エドワーズ

11:22時金、2018年4月6日には、カイル・コープランド[email protected]
書きました：

@dafflhttps ：//github.com/dafflここにサービスとORMの私の最良の推測があります

サービス指向の方法：

//フック後：疑似コードこれはテストしていません

const {result、app} =コンテキスト;

result.map（async team => {
constplayers = await app.service（ 'team-player'）。find（{
クエリ：{
teamId：team.id
}
}）。then（results => {
app.service（ 'player'）。find（{
クエリ：{
playerId：results.playerId
}）;
}）;

team.players =プレーヤー;
}）

コンテキストを返します。

ORMの方法：

//フック前：これは機能します
context.params.sequelize = {
含む： [ {
モデル：context.app.service（ 'player'）。Model、
として： 'プレーヤー'、
属性：['名前']、
使って： {
属性：[]
}
}]、
生：false
};

コンテキストを返します。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/feathersjs/feathers/issues/852#issuecomment-379336187 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ACyd4hzQdRSLJ5tBm7I_BkOFPDYkyhU7ks5tl7JKgaJpZM4TJRE4
。

n:m関係は、CRUD操作全体で調整するのに最も難しい関係です。 私はいつも「ブログ投稿」と「タグ」を私の古典的なn:m例で使用しています。 考慮しなければならない3つの異なるシナリオがあります。

1. 新しいタグのみでブログ投稿を作成/更新します
2. 既存のタグのみを使用してブログ投稿を作成/更新します
3. 新規タグと既存タグの組み合わせでブログ投稿を作成/更新します

#3ははるかに複雑です。 ただし、そのシナリオを解決することで、最初の2つを無料で解決できます。 これが私がそれにアプローチする方法です：

• 制約：クライアントに関する限り、タグをブログ投稿に関連付けることは、常にブログ投稿サービスを介して行われます（簡単にするため）。 次のペイロードで単一のブログ投稿のみを更新するとします。
  js { id: 123, title: 'My first blog post', body: '...', tags: [ { id: 111, text: 'tag-1' }, { id: 222, text: 'tag-2' }, { text: 'new-tag' } // new tags will not have an "id" ] }
• ブログ投稿サービスでは、最初にブログ投稿を更新することに重点を置きます。後で使用するためにタグを保存します。 ブログ投稿を正しく更新できるように、タグデータをbeforeフックに「キャッシュ」する必要があります。
  js (context) => { if (context.data.tags) { context._tag_data = context.data.tags; delete context.data.tags; } return context; }
• アフターフックで、タグを処理します。 まず、新しいタグを作成する必要があります。
  js async (context) => { const tags = context._tag_data; if (tags && tags.length) { // tags without an "id" are considered new const existingTags = tags.filter(t => t.hasOwnProperty('id')); const newTags = tags.filter(t => !t.hasOwnProperty('id')); await tagService.create(newTags).then(createdTags => { // update the context._tag_data to contain the existing and newly created tags context._tag_data = existingTags.concat(createdTags) }) } return context; }
• 最後に、すべてのタグをブログ投稿に関連付けます。
  js async (context) => { const tags = context._tag_data; if (tags && tags.length) { const blogPostId = hook.result.id; const mappings = tags.map(t => ({ tagId: t.id, blogPostId })); await postTagsService.create(mappings).then(() => { // Put the tags on the final result hook.result.tags = tags; }); } return context; }

それは_簡単_ではないように思えますが、私はすべてのユースケースについて考えることに多くの時間を費やしました。上記は、全体的なユーザーフレンドリーなソリューションについて私が見る唯一の方法です。 私は提案を求めていますが、単一の操作でデータを作成して関連付けることを可能にする確立されたユーザビリティ規則（Wordpress、StackOverflowなど）に対処する必要があります。

また、Sequelizeを使用すると、これが必要以上に難しくなると思います。 モデルメソッドは開発者として直感的に見えますが、APIクライアントの観点からは、メソッドを呼び出すのではなく、データを送信するだけです。

たとえば、既存のIDを使用したり、IDのリストを指定したりして、関連付けを更新または作成することはできません。これは非常に直感的ではありません。

私はこれと同じ問題を抱えていますが、使いやすく安全なものは見つかりませんでした。

ここでも同じ問題があります。 @ DesignByOnyxが今のところそのアプローチを採用することに感謝します。 他の誰かがこれに対する直感的な解決策を思い付きますか？

私もこれをフォローしていて、現在、今週新しいプロジェクトにこれを実装しようとしています

@daffl提案をありがとう、それは今のところ私のために働いた。

ちょっとしたメモとして、実際には@DesignByOnyxが示すよりも

欠点は、更新のたびにかなりの不要な作業を行うことです（変更されていない可能性のあるタグのリストを削除して保存します）。

私が考えることができる唯一の選択肢は、更新する前に関係を読み取り、必要な[作成、更新、削除]の最小数を計算することです。 タグの数が多い場合は、それだけの価値があるかもしれません。

別のアイデアは、関係のサービスを作成し、IDで各エントリを識別し、[投稿、タグ]のペアごとに個別に呼び出すことだと思います。 これはネットワークリクエストでは非効率に思えますが、概念的にはすべてを一度に実行するよりも少し簡単です。

class CustomService {
  constructor(options) {
    this.options = options || {};
  }

  /**
   * <strong i="5">@params</strong> {object} data - Sent in from client
   * <strong i="6">@params</strong> {INT} data.building_id - ID of the building from the Building Model
   * <strong i="7">@params</strong> {INT} data.contact_id - ID of the contact from the Contact Model
   */
  create = async (data, params) => {
    if (isNaN(data.building_id)) {
      throw new errors.BadRequest('Building ID MUST be a Number', data);
    }
    if (isNaN(data.contact_id)) {
      throw new errors.BadRequest('Contact ID MUST be a Number', data);
    }

    const building = await this.options.building.get(data.building_id);
    const contact = await this.options.contact.get(data.contact_id);
    const buildingContacts = await building.addContact(contact);

    return buildingContacts;
  };
}

export default app => {
  app.use(
    'api/v1/building_contacts',
    new CustomService({
      building: app.service('api/v1/building'),
      contact: app.service('api/v1/contact')
    })
  );

  const buildingContactsService = app.service('api/v1/building_contacts');

  buildingContactsService.hooks(hooks);
};

私が直面している問題は、連絡先が建物にすでに存在する場合、郵便配達員にpage not foundエラーが発生することです。
連絡先が建物に追加されたことがない場合、これは問題なく実行されます。

何か案は？

  const tags = context._tag_data;
  if (tags && tags.length) {
    const blogPostId = hook.result.id;
    const mappings = tags.map(t => ({ tagId: t.id, blogPostId }));
    await postTagsService.create(mappings).then(() => {
      // Put the tags on the final result
      hook.result.tags = tags;
    });
  }

これは、中間テーブル用のフェザーサービスを作成する必要があることを意味しますか？ 不要なサービスのようです。 ここでデータベースと対話する別の方法はありますか？

「関係」サービスが必要であり、3番目のサービスとしての使用を回避するために私が行ったすべての試みは、無駄であるか、他のコードを不当に困難にしました。 これは私がn:m関係を扱ったときに持っていた最大の「あはは」の瞬間

このシナリオについて考えてみてください。ブログ投稿と既存のタグがあり、2つを関連付けたいと考えています。 ブログ投稿自体を作成または更新するのではなく、タグを作成または更新するのでもありません。単に2つの間の関係を定義するだけです。 ブログサービスやタグサービスに触れる必要はありません。「blog-tags」サービスだけに触れる必要があります...そのためには存在する必要があります。

もう1つの（より複雑な）オプションは、ブログサービスまたはタグサービスを使用して関係を更新しようとすることです。 どちらを使いますか？ それをチームにどのように伝えますか？ それが両方の方法で発生することを許可すると、維持するコードが2倍になり、メンタルモデルも難しくなります。 関係自体に3番目のサービスがある場合、これらの問題はすべて解消されます。