Ну execution на папку означает переходить в нее и читать список в ней.

ага, понял

Я бы вообще наверно перенес tmp из системного в папку приложения.

Ну execution на папку означает переходить в нее и читать список в ней.

странно просто, что в другом месте кода не возникало подобной ситуации о_х

Тогда легче можно очищать кэш

Фиг его знает :)

Так ведь навскидку не скажешь.

Может он пересоздавался тут а там новый создался

ну да, согласен, конечно

Сложно сказать

Сложно сказать

спасибо большое!

привет, подскажите плиз по архитектуре. Вот у юзера есть адреса. При создании заказа юзер вводит новый адрес или выбирает из списка. Этот адрес должен добавится к юзеру если такого небыло. Самое главное что в заказе тоже должен быть этот адрес, но не ссылкой, а для истории. То есть адрес свой юзер может удалить, а в заказе он должен остаться. Для этого использовать два разных класса как-то не оч удобно, придется туда сюда гонять данные

может вести отдельную табличку order_history и просто туда копировать аля лог?

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

Добрый день подскажите пожалуйста в чем может быть причина отправки писем (стандартный мейлер + gmail) только после перезапуска службы bin/console gos:websocket:server —env=dev ?

может вести отдельную табличку order_history и просто туда копировать аля лог?

Исходя из описания, проще всего добавить поле isArchived у сущности Address

привет, подскажите плиз по архитектуре. Вот у юзера есть адреса. При создании заказа юзер вводит новый адрес или выбирает из списка. Этот адрес должен добавится к юзеру если такого небыло. Самое главное что в заказе тоже должен быть этот адрес, но не ссылкой, а для истории. То есть адрес свой юзер может удалить, а в заказе он должен остаться. Для этого использовать два разных класса как-то не оч удобно, придется туда сюда гонять данные

у заказа данные никуда гоняться не будут. Ты сделал заказ на адрес - записал адрес в историю адресов.

если такой уже был соответственно не добавляешь

просто дублируешь данные и все

заказы отдельно - пользователи отдельно, они никак не пересекаются, все просто и все согласно требованиям

просто дублируешь данные и все

вопрос куда дублировать, отдельную таблицу лучше или в сам заказ?

Исходя из описания, проще всего добавить поле isArchived у сущности Address

не надо просто делать это общую таблицу между заказами и юзерами - будет меньше боли

вопрос куда дублировать, отдельную таблицу лучше или в сам заказ?

в сам заказ

запомни - дублирование кода не проблема. Проблема дублирование логики. И еще одно - сначала читаемость и понятность кода а потом уже проблемы дублирования. Далеко не всегда DRY полезен.

есть еще связанность и прочее

это намного опаснее чем просто тупое дублирование кода

в сам заказ

мне не очень нравится, что приходится между этими адресами через dto туда сюда, имеется ввиду между адресом юзера и адресом в заказе

мне не очень нравится, что приходится между этими адресами через dto туда сюда, имеется ввиду между адресом юзера и адресом в заказе

ну не юзай dto

сделай VO под названием Address и гоняй его

и все будут счастливы

embedable штука и все

а сущность для юзера назови UsedAddress

вуаля

class UsedAddress { private $user; // User private $address; // Address }

сделай VO под названием Address и гоняй его

А чем тут отличается? Они же вроде как отличаются просто наличием или отсутствием методов каких-то кроме геттеров и сеттеров.

у DTO не должно быть никакого поведения, у VO может... и ну VO как бы обычно малые объекты представляющие какие-то неделимые типы

отличие в инкапсуляции и полиморфизме :)

у DTO не должно быть никакого поведения, у VO может... и ну VO как бы обычно малые объекты представляющие какие-то неделимые типы

Ну вот.

не совсем понял. Вот у user адреса как $addresses ArrayCollection. По факту это просто crud. Юзер может удалить, добавить, обновить адрес. У заказа же наоборот address как Embedded и это отдельный класс OrderAddress. Суть в том, что и в том и другом случае форма мапится на одну и ту же dto, из которой потом появляются адреса (форма создания заказа и форма добавления адреса). Такой подход нормальный или фиговый? Ну и почему этот вопрос всплыл, потому что помимо адресов есть еще различные сущности, которые надо так же дублировать в заказ. То есть подход масштабируется)))

Если попроще, то копировать... сделать, например, VO\Address::createFromAddressEntity(Address $address) и поместить в Order. И приделать к доктрине ресолв типа VO\Address с сериалайзом в json

Если посложнее, то таблица адресов с softDelete и связью и из юзера и из заказа, но нужно тогда еще запредить редактирование, если есть связь с заказа, т.е. делать редактирование через копирование

не совсем понял. Вот у user адреса как $addresses ArrayCollection. По факту это просто crud. Юзер может удалить, добавить, обновить адрес. У заказа же наоборот address как Embedded и это отдельный класс OrderAddress. Суть в том, что и в том и другом случае форма мапится на одну и ту же dto, из которой потом появляются адреса (форма создания заказа и форма добавления адреса). Такой подход нормальный или фиговый? Ну и почему этот вопрос всплыл, потому что помимо адресов есть еще различные сущности, которые надо так же дублировать в заказ. То есть подход масштабируется)))

если напомнишь мне то скину тебе пример чуть позже

Интересная проблема возникла. Может кто-то решал подобное. Обновляюсь с 2.8 на 3.2. И формы сейчас нельзя инстанциировать руками. То есть в $this->createForm() нельзя передавать инстанс. Так вот в этом коде туда передается форма, которая сделана как сервис. То есть она вызывается из контейнера, передается в createForm(), и так же используются методы, созданные в ней. И вот именно использование самостоятельно созданных методов все и обламывает. Было ли у кого-то подобное? :)

Если посложнее, то таблица адресов с softDelete и связью и из юзера и из заказа, но нужно тогда еще запредить редактирование, если есть связь с заказа, т.е. делать редактирование через копирование

очень плохая идея

Если попроще, то копировать... сделать, например, VO\Address::createFromAddressEntity(Address $address) и поместить в Order. И приделать к доктрине ресолв типа VO\Address с сериалайзом в json

неймспейсы типа Entity или VO это рак

"а я на коне" забыл

очень плохая идея

обоснование то будет?

$formType = $this->get('import_guests_form_type'); $form = $this->createForm($formType, $importGuests); if ($formType->getStep()) { // blabla } Как вот это можно переписать на 3.2?

Интересная проблема возникла. Может кто-то решал подобное. Обновляюсь с 2.8 на 3.2. И формы сейчас нельзя инстанциировать руками. То есть в $this->createForm() нельзя передавать инстанс. Так вот в этом коде туда передается форма, которая сделана как сервис. То есть она вызывается из контейнера, передается в createForm(), и так же используются методы, созданные в ней. И вот именно использование самостоятельно созданных методов все и обламывает. Было ли у кого-то подобное? :)

То ли я не понял проблему, то ли её нет: передавать инстанс можно, пример есть в мануале https://symfony.com/doc/3.2/forms.html Искать на странице по $this->createForm(

Passing type instances to FormBuilder::add(), Form::add() or the FormFactory is deprecated since version 2.8 and will not be supported in 3.0. Use the fully-qualified type class name instead (CA\GuestBundle\Form\Import\ImportGuestsType).

А, понятно. В любом случае, в примере видно, что надо просто ::class в качестве первого аргумента использовать

Само собой. :)

Я и говорю.

Но тогда мы не сможем получать инстанс формы за пределми. А он ведь нужен

То есть проблема исключительно в том, чтобы DI работал? Если да, то вот ответ: https://github.com/symfony/symfony/issues/17013#issuecomment-253493082

Нееее. Проблема не в DI.

С DI как раз все понятно

Посмотри еще раз код, который я запостил

обоснование то будет?

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

Проще сделать жсон поле и хранить массив)

да проще ваше все в жсон и в файл

В файл нет

А в поле да

в excel, зато потом сразу по FTP грузишь и директору отправляешь

Проще сделать жсон поле и хранить массив)

В этом варианте я ничего не теряю, а жизнь немного упрощаю

Фу, грузить директору по фтп в 2017

ERROR: S client not available

точно, нормальную форму придумали дрочеры

В экселе(

точно, нормальную форму придумали дрочеры

Академические концепции - это клево и хорошр и ими надо уметь пользоваться

ага, куда проще не забивать себе голову и класть все в json :)

Дррчеры или нет не знаю, а люди умные были, да

ага, куда проще не забивать себе голову и класть все в json :)

Очень часто да

а я что, спорю что это проще сдеать ;) конечно проще ;) особо когда нахреначил и свалил на другую работу ;)

Да не, потом тоже проще часто

В поддержке

ребят

всем привет

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

у меня работает параллельно 50 процессов каждому надо записать в одно и тоже поле в сущности некоторое число грубо говоря инкрементировать предыдущее число на + 1

т.к. они работают параллельно, то получать предыдущее значение вообще не вариант из 50 туда записать успевают порядка 10

В Бд?

реализовывал как-то так: $buffer = $объект->получитьЗначениеПоля(); $объект->записатьЗначениеПоля($buffer+1):

т.к. они параллельны, то записывают штук 10

Мускль?

да, бд на mySQL

Если да, то я бы использовал RAW запрос. Тогда запись была бы атомарной.

Без SELECT UPDATE

просто UPDATE table SET field=field+1;

оу

даже не копал в эту сторону

спасибо тебе большое, сейчас попробую

http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/transactions-and-concurrency.html

всё же спрошу так как работа вся происходит в рамках двух команд, одна из них плодит процессы а другая уже в процессе инкремент делает если я буду использовать вариант с raw запросом я могу вынести эту функцию, с raw, в сервис, например а в процессе её уже дёргать и через doctrine делать запрос?

извини, опять же, за возможно где-то неверную терминологию

Да без проблем.

Спасибо ещё раз :)

всем привет. помогите, пожалуйста, переделать sql запрос в dql или doctrine query builder. пол дня бьюсь, не получается. сам sql запрос: select dish.name as Блюдо, sum(history.qty) as Количество from history inner join dish on history.dish_id = dish.id left join shop on dish.shop_id = shop.id where year(history.order_date) = '2017' and shop.id = 8 group by Блюдо having Количество > 10 order by Количество desc;