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

У меня проблема с моим сопоставлением. Я не могу заставить его работать. У меня есть базовый базовый класс:

/** * @Entity * @Table(name="actions") * @InheritanceType("JOINED") * @DiscriminatorColumn(name="type", type="string") * @DiscriminatorMap({"FOO" = "FooAction", "BAR" = "BarAction", ...}) */ abstract class AbstractAction { ... } 

У меня есть куча разных действий, все с разными полями. Например:

 /** * @Entity * @Table(name="actions_foo") */ class FooAction extends AbstractAction { ... } 

Но одно из моих действий ( BarAction ) не требует дополнительных полей, кроме тех, которые предоставляются AbstractAction . Но как я могу это отобразить? Я попытался @Table или использовать тот же @Table что и AbstractAction , но не имеет никакого эффекта.

 /** * @Entity * @Table(name="actions") */ class BarAction extends AbstractAction { ... } 

@Table дает мне PDOException о недостающей таблице BarAction . Использование @Table базового класса дает мне:

 PDOException: SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not match number of tokens 

Итак, как это сделать?

Изменить: До сих пор я пробовал еще две вещи.

Я попытался удалить @Entity а также @Table из BarAction надеясь, что таким образом больше не потребуется таблица базы данных. Это не работает. Вместо этого я получаю эту ошибку:

 Doctrine\ORM\Mapping\MappingException: Class BarAction is not a valid entity or mapped super class. 

Затем я попытался создать таблицу actions_bar в моей базе данных с единственным id столбца внешнего ключа. Затем я сопоставил BarAction . Это работает (yay!), Но он чувствует себя крутым и уродливым, чтобы иметь дополнительную таблицу SQL, которая мне вообще не нужна.

Итак, все еще ищу лучший способ …

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

И родительский класс может использовать только один тип наследования, либо наследование таблицы классов, либо наследование одной таблицы.

В этом случае, если вы не хотите иметь таблицу с единственным столбцом идентификатора, вам нужно изменить свою модель данных.

Может быть, это может помочь или добавить что-то новое. Это не ответ, а просто принятие концепций.

Если вы думаете о классах, и вы понимаете свою модель как: AbstractAction, FooAction и BarAction, это, вероятно, потому, что вы можете использовать одни и те же методы в подклассах или расширить какой-либо родительский метод.

Если вы решите представить эти классы с таблицами, и вы выберите «все в одной таблице с атрибутом дискриминатора», я думаю, что у вас нет проблем. Для BarAction у вас будет регистр с дискриминатором = «BarAction», который будет представлен классом сущности BarAction.php.

С другой стороны, если вы решите использовать другую таблицу, я считаю, что вам нужна одна таблица за «класс». Таблица для BarAction будет содержать только поле ID для AbstractAction, но его необходимо «классифицировать» (или различать) ваши данные как FooAction.

В целом, я думаю, что три таблицы, представляющие три класса, являются прекрасным решением, хотя таблица BarAction просто содержит ссылку на родительскую таблицу.

Я думаю, вам не нужно вручную создавать таблицу в своей базе данных.

У меня почти такая же структура, что и доктрина (2.3). Однако вы должны поместить @Entity et @Table в каждый из подклассов. Ошибка Недопустимый номер параметра: количество связанных переменных не совпадает с числом токенов, которые не могут быть связаны. Это может быть проблема с кешем, вы попробовали ее промыть?

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