Роман Романов

https://symfony.com/doc/current/reference/constrai...

class UserDTO
{
    /**
     * @var AutoDTO
     * @Assert\Valid 
     */
    private $auto;

   public function setAuto(AutoDTO $auto)
    {
        $this->auto = $auto;

        return $this;
    }
}

class AutoDTO
{
    /**
     * @var PriceDTO
     * @Assert\Valid 
     */
    private $price;

   public function setPrice(PriceDTO $price)
    {
        $this->price = $price;

        return $this;
    }
}

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

дополню ответ Юрий

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

Все сущности заворачиваются в прокси объекты, что бы работала "магия" вроде ленивой подгрузки и т.д. Именно по этому в сущностях "больше" чем есть на самом деле.

По поводу коллекций, в Doctrine есть такая штука как Collection. Вы должны понимать что в доктрине вы оперируете не табличками в базе, а объектами. Строите именно объектную модель вашей системы. В этом ключе можете почитать что такое "агрегат сущностей". В вашем случае у вас агрегат будет состоять из двух сущностей. Product и его Image. Например если вы захотите сделать добавление картинок, вы можете сделать так:

/**
 * usage: $product->addImage($image);
 */
public function addImage(Image $image)
{
    $this->images->add($image);
}

А коллекция сама выполнит persist новой сущности. Таким образом количество репозиториев уменьшается до количества корней агрегатов сущностей. В вашем примере "корнем", то есть вершиной графа взаимоотношений объектов в контексте продуктов, является сам продукт. А потому репозиторий мы будем делать только для продуктов. Все остальное внутри оного разруливается либо при помощи коллекций.

При работе с доктриной вообще полезно представлять себе, что никакой базы данных у вас нет. Что данные просто живут между запросами где-то там, в памяти. Это должно помочь вам "абстрагироваться" и перестать смешивать "сущности" и "таблицы".

К примеру "новички" в доктрине любят персисть сущность даже для обновления. Они путают `persist` и `save`. Так вот, если вы загрузили сущность из базы через доктрину, то сущность уже попадает в unit of work. И делать persist уже не нужно, этот метод только для того чтобы доктрина узнала о чем-то новом. А так она и так знает про эту сущность. В итоге вы можете просто что-то поменять и вызвать flush. То есть репозиторий - это тупо хранилище. Хранилище умеет хранить. Изменять то, что оно хранит оно не может.

Так же рекомендую на тему репозиториев почитать это:

www.whitewashing.de/2013/03/04/doctrine_repositori...

Ну и в целом.

https://www.youtube.com/watch?v=rzGeNYC3oz0 - доклад о том как готовить доктрину от авторов оной.

От себя лишь добавлю простые правила:

- Не используйте напрямую доктриновские репозитории. Пишите свои, а в них уже юзайте доктриновские. Не стоит размазывать доктрину по всему проекту, потом это будет нереально поддерживать.
- Не наследуйтесь от EntityRepository. Это внутренний механизм доктрины общего назначения. Используйте их в своих репозиториях со своим интерфейсом, повышая специфичность и ужесточая контроль за тем кто что юзает.
- Старайтесь использовать entity manager только в своих репозиториях и каких то небольших сервисах. Не размазывайте все по всюду.

что очень сильно срет память.

Доктрина гарантирует вам что в памяти будет всегда только один инстанс сущности. То есть если у вас есть 10 объектов одного типа и имеющих один объект, это все будут ссылки на одну сущность. В вашем случае у вас просто циклическая ссылка между продуктами и изображениями. dump циклические ссылки не особо умеет.

Это логичное ограничение, дабы не возникало ситуаций что вы обновили что-то в одном экземпляре сущности и что-то в другом, и в базу попадут только часть изменений. За подробностями - читайте документацию к доктрине в отношении UnitOrWork и Identity Map.

(myFunc()->var)()->var

Я вчера пол-вечера потратил на решение проблемы господина, всё разжевал, выдал рабочий код и вот опять.
Да смените свой хостинг в конце концов. Ежу понятно, что в нем проблема. Код в норме.

Данный код может выполняться очень долго только по одной причине.
По причине того что Вы очень долго получаете данные с удаленного сайта.
А происходить это может по двум причинам: либо у Вас медленный интернет-канал между Вами и сервером, либо удаленный сервер очень долго отвечает на Ваш запрос.
И кстати curl_close($ch);

Сперва отправь изменения в правильную ветку (в удалённом репозитории проверь что в task1 все изменения были приняты, т.е. что последний коммит прошёл, иначе есть шанс потерять всю работу)
git push origin task1

Потом на мастере получи все изменения из удалённой репы
git checkout master
git fetch --all
git rebase origin/master

Обресетить изменения и вернуть их на мастер с форсом
git reset --hard HEAD~1
git push origin master -f

А не правильней ли было бы использовать position()

descendant::tr[position() = 1 or position() = 3]/td[1]

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

1) самоорганизованность
2) невозможность быстро получить фидбек/нужную информацию от коллег
хотя и то и то лечится выстраиванием расписания skype-call ов