Максим Федоров

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

На машине разработчика
Если все сделано аккуратно (когда работали с миграциями), то можно удалить все таблицы и попробовать сгенерировать diff — он сделает актуальную миграцию, которая необходима. Далее нужно удостовериться — не было ли придуманных вне ORM миграций и таблиц, крч сверить с боевой схемой. Также возможно миграции несли некоторые данные (ну например коды валют, которых всего 5-10 вы решили миграцией занести или пара дефолтных значений из таблицы settings, и подобные случаи) — нужно будет руками это повторить (или не повторять, если не нужно).
Если вы добились, что ПУСТОЙ БД накаткой миграций получается ровно то, что достигалось ранее, то:

• вы спокойно можете удалить старые миграции и коммитить эту одну большую
  
• перед выкаткой на прод — вы должны текущую миграцию занести в таблицу migration_versions руками
  

Done!

Все делается очень легко, мне как-то достался проект без доступа к старому GIT (и почему-то без миграций), но с боевой БД. Пришлось проделать приблизительно все тоже самое (не считая болевого обновления Symfony с 2.7 до 3.4 с Сонатой, было больно :):):))...
Все проделывания с миграциями заняли от силы полтора часа (в виду молодости и не опытности), было пару подводных моментов (типа у некоторых бандлов из vendor были свои папки со своими мииграциями) и данные нужны были. некоторые, а так все относительно легко

Аннотация @Accessor

/** @Accessor(getter="getName") */
private $name;

public function getName()
{
     return $this->name;
}

При вызове указанного геттера произойдет вызов и запрос. Соответственно lazy вернет результат.

Если yaml, то в той же доке указано как задать аксессор.
Не забудьте почистить кеш (не всегда чистится консольной командой, удалите папку jms - когда с 3й работал, то были такие глюки) .


А вообще, если пишите с нуля, то знайте — от JMS Serializer все уходят в сторону Symfony Serializer
В контейнере уже должен быть у вас сервис @serializer сразу после установки компонента и можно просто заинжектить через SerializerInterface в конструкторе

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

Доктрине фиолетово на приватность/открытость ваших свойств, ровно как и на наличие методов для их
записи/чтения, кроме того этого сеттеры/геттеры распространены (абсолютно везде), но все равно это признак плохого кода, писал об этом статью на Хабре: Геттеры/сеттеры и проблема с инкапсуляцией.
А так Доктрина работает с объектами через рефлексию.

Как выводить нужные в другом слое данные, которые нужны для отображения, а не для бизнес-логики — DTO,
отвечал на днях: Что делать, если нужно получить часть данных сущности?

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

@Column
Marks an annotated instance variable as "persistent". It has to be inside the instance variables PHP DocBlock comment. Any value hold inside this variable will be saved to and loaded from the database as part of the lifecycle of the instance variables entity-class.
https://www.doctrine-project.org/projects/doctrine...

Итого:
Рекомендую или DTO или сервис (как указал BoShurik), который вернет ссылку, при том в этот сервис можно скормить роутер и создавать сылку не по названию сущности, а по названию роута — это облегчит потом смену сразу всех роутов одного типа, если не меняете название. А вообще и DTO и сервис нужны. В любом случае сущность знать о роутах ничего не должна, тем более этих роутов под одну сущность можеть быть куда больше, чем /blog/ и меняться это может довольно часто...

Нужно добавить маппинг в настройках /config/doctrine.yml (ну или в том файле, где эти настройки лежат):
Для 4 версии: https://github.com/symfony/demo/blob/master/config...

doctrine:
     orm:
            mappings:
                  UserEntities:
                       type: annotation
                       dir: "%kernel.root_dir%/../src/Models/User/Entity"
                       is_bundle: false
                       prefix: <YOUR_NAMESPACE>\Models\User\Entity

Removed deprecated method JsonSerializationVisitor::addData, use :visitProperty(new StaticPropertyMetadata('', 'name', null), 'value') instead

Источник: https://github.com/schmittjoh/serializer/blob/mast...

В UPGRADING.md обычно в библиотеках пишут, что поменяли из обратносовместимого...

Для чего сделали: (довольно поверхностно посмотрел код на Гитхабе)
повысили уровень абстракции — использовали полиморфизм, чтобы можно было более гибко работать с сериализацией/десериализацией/группами и прочее для работы со свойством сущности, для управления условиями добавления этого поля и т.д. возложив ответственность на объект MetaData (на языке паттернов: Стратегия)

Дискусия появления решения: https://github.com/schmittjoh/serializer/pull/45

1 СПОСОБ:
вам нужно логику выборки вынести в репозиторий DigRepository в некий метод
там же в репозитории сделать метода для получения количества
все этих методы будут работать с неким общим методом, который возвращает QueryBuilder.
Рекомендую начать с этого способа

2 СПОСОБ:
Сделать некий объект Criteria, который бы собирал нужный QueryBuilder и отдавал нужный ответ (сами данные или их число)

ПРЯМОЙ ОТВЕТ:
Вам нужен еще один запрос почти с тем же набором для QueryBuilder, только запрашивать $qb->select('count($dig.id)')
И в конце $qb->getQuery()->getSingleScalarResult()

Потому и предложил выше вынести код туда, где ему место и сделать его более общим, чтобы можно и поиск делать и запрашивать количество записей

Экономически -- так и так делать 2 запроса, но зато код проще станет и удобнее будет его переиспользовать

Можно ли организовать доступ к полям сущностей так, как это было бы при наследовании, при этом храня общие поля в таблице Users (как это сейчас в базе и есть)?
class Saler extends User{...}

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

Вот то — поля родительской сущности в отдельной таблице, в своей только индивидуальные
Class Table Inheritance

UPD: Немного перепутал с типом наследования, не single table, а class table конечно. Возможно вы разобрались, но другим пометки

https://www.doctrine-project.org/projects/doctrine...