Карта настраиваемого дискриминатора Doctrine

Итак, я работаю над интеграцией Symfony 3 в устаревшую кодовую базу, и по большей части все в порядке. К сожалению, у меня возникла проблема с наследованием одной таблицы с помощью классного дискриминатора. ПРИМЕЧАНИЕ. Я не могу изменить схему (по крайней мере, в ближайшее время), потому что она привязана к большому количеству старого кода.

У меня классический Person -> Employee mapping. При этом у меня есть 2 таблицы:

  • Компания
  • Человек

что переводится на 3 объекта

  • Компания
  • Человек
    • Работник

Это кажется довольно простым, за исключением того, что единственный жизнеспособный дискриминатор - это company_id, который представляет собой столбец для человека, обозначающий, к какой компании принадлежит этот человек. Если company_id = 1, это сотрудник, в противном случае - обычный человек.

Насколько я могу судить, мне понадобится карта, которая выглядит так:

/**
 * @InheritanceType( "SINGLE_TABLE" )
 * @DiscriminatorColumn( name = "company_id", type = "integer" )
 * @ORM\DiscriminatorMap({
 *      1 = "Employee",
 *      2 = "Person",
 *      3 = "Person",
 *      ...
 *      5001 = "Person"
 *   })
 *
 * @ORM\Table(name = "person")
 * @ORM\Entity
 */
class Person
{}

Такой способ отображения невозможно сохранить. Я осмотрелся, но не нашел для этого хорошего решения. На данный момент я использую суперкласс Mapped, а затем указываю как Person, так и Employee на таблицу людей, которая работает с точки зрения кода, но если я запускаю схему, проверьте ее ошибки из-за того, что имя таблицы уже существует. Это затрудняет поддержание сопоставления.

Стоит ли изучать PHP в 2026-2027 годах?
Стоит ли изучать PHP в 2026-2027 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Symfony Station Communiqué - 7 июля 2023 г
Symfony Station Communiqué - 7 июля 2023 г
Это коммюнике первоначально появилось на Symfony Station .
Symfony Station Communiqué - 17 февраля 2023 г
Symfony Station Communiqué - 17 февраля 2023 г
Это коммюнике первоначально появилось на Symfony Station , вашем источнике передовых новостей Symfony, PHP и кибербезопасности.
Управление ответами api для исключений на Symfony с помощью KernelEvents
Управление ответами api для исключений на Symfony с помощью KernelEvents
Много раз при создании api нам нужно возвращать клиентам разные ответы в зависимости от возникшего исключения.
1
0
222
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Честно говоря, я не уверен, возможно ли что-то подобное, потому что это было бы безумием для сгенерированных запросов (особенно если у вас много записей).

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

хм, у меня было ощущение, что это было бы невозможно. Было бы здорово создать новую колонку, но некоторые руководители несколько раз наложили вето на это предложение. Хотя вид может просто работать. Спасибо.

buphmin 06.06.2018 03:09

Тогда я думаю, что просмотр будет твоим выходом.

M. Kebza 06.06.2018 04:24

Другие вопросы по теме