Для "своих" таблиц (которые используются только в этом проекте) - там orm и всё нормально.

Раньше доктрина умела строить сущности на основе схемы БД)

А теперь только наоборот

\PDOStatement $statement
       for ($i = 0; $i < $statement->columnCount(); ++$i) {
           $meta = $statement->getColumnMeta($i);

В чем проблема? Из Dbal statement не проблема получить

OCI8 :-)

+ в doctrine 3x вырезали это всё

Там вообще отвязались от PDO

А там типы полей меняются так часто и вы можете даже с этим работать?
ЧТо мшает написать мапинг таблица поле тип один раз и использовать его?

Таблиц много. И не всегда это таблицы. Бывает тупо запрос

Фича сама по себе не появится, смысл ждать?

Так я уже и не жду. Просто обновил свой костыль и всё. Работает, зараза.

Тогда на dbal 3 не рано переходить, просто потеряна фича (удобство её использования)

Скорее всего буду переходить. Пока на 2ке работает.

Народ. А можно мыслишки на тему послушать ?
Есть сущность - Напоминание
Оно может быть для зарегистрированного пользователя (юзер ИД)
или для просто по мылу для кого угодно (это в плане куда шлем напоминание)

так же оно может быть для разных обьектов - событие(по сути некая конкретная дата), повторяющиеся событие(раз в день) и конкретное событие из повторяющегося события

вот я думаю как лучше организовать структуру сущностей
какие есть мысли
1. одна на все целиком - мысль не очень нравится
2. наследование - тоже плоховато потому как дети и будут напоминалками как и родитель, но у всех детей будут свои методы
3. сделать интерфейс и его реализовать - аналогично как у п.2 - вряд ли это можно обьеденить
4. делать на каждый вариант свою сущность ? (RegisteredUserEventReminder, RegisteredUserRecurringEventReminder...) - такое себе удовольствие...

кто что скажет ?

У нас такое сделано на коллбэках. Сущность одна, бд одна, дальше логика рулится коллбэком для конкретного уведомления.

PS: это отдельный сервис уведомлений.

т.е у вас по сути
ReminderEntity
  setUserId
  setEmail
  setTarget(event|recurringEvent|specificDateAtRecurringEvent)
?

типа мой пункт 1 ? я правильно понял вашу мысль ?

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

Да.