Цикл 3 - удаление или редактирование вложенных моделей с использованием таблицы сопоставления - PullRequest
0 голосов
/ 10 мая 2019

Вопрос: существует ли петлевой способ обработки обновлений, если я храню выбранные значения в таблице сопоставления? Иначе, есть ли правильный аргумент (кроме того, он облегчит вашу жизнь) в поддержку второго подхода хранения городов в виде массива идентификаторов.

Context У меня есть loopback 3 сервер API с MySQL источником данных. Для хранения значений множественного выбора я использую таблицу сопоставления. Например, у человека много городов. Итак, есть таблица PersonCity, которая имеет person_id и city_id. И у меня есть отношение hasMany, которое выглядит так:

"cities": {
      "type": "hasMany",
      "model": "PersonCity",
      "foreignKey": "person_id",
      "options": {
        "nestRemoting": true
      }
    }

В моем приложении пользовательского интерфейса требуется раскрывающийся список со всеми городами, и человек может выбрать несколько городов. Я могу узнать города человека, позвонив в API, например, persons/{id}/cities, что приводит меня ко всем городам из таблицы PersonCity, где person_id - это id, упомянутый в вызове API.

Ответ, который я получаю, выглядит следующим образом:

[{
  id: 14,
  person_id: 1,
  city_id: 1
},
{
  id: 19,
  person_id: 1,
  city_id: 2
},
{
  id: 34,
  person_id: 1,
  city_id: 3
},{
  id: 34,
  person_id: 1,
  city_id: 4
}]

и затем я могу извлечь все city_id, чтобы получить выбранные города для значения моего раскрывающегося списка.

Проблема возникает при редактировании. Допустим, я хочу удалить один из выбранных городов и добавить еще два.

Один из подходов состоит в том, чтобы удалить город с помощью delete API-вызова, подобного этому /persons/1/cities/{id}, а затем сделать вызовы для новых городов. И код UI должен позаботиться об этом. В этом случае пользовательский интерфейс должен иметь информацию о предыдущих городах, определять, какие из них следует удалить, а какие добавить.

Другой подход, который делает жизнь намного проще, - это забыть таблицу отношений и сопоставления, просто сохранить города в массиве city_id внутри person и затем обновить человека новым массивом. Массив - это то, что собирает мой блок выбора, и он выглядит естественным.

Я не эксперт по БД, но, следуя правилам проектирования БД, я получил таблицу сопоставления для хранения этих данных, и жизнь для пользовательского интерфейса очень сложна.

...