кто что думает о хранении данных в ES? пару лет назад один из кор контрибьюторов обещал, что скоро уже можно будет ES утилизировать как документную базу. удобно было бы и данные держать и сразу полнотекстовый поиск.

ну кто-то так и делает)

https://www.elastic.co/guide/en/elasticsearch/resiliency/current/index.html

но вообще как бы тот же постгрес или мускуль тебе тоже полнотекстовый поиск предоставляют

всеравно "как у гугла" не получится

немного не понял формулировки. То есть у нас между "принял запрос" и "записал в базу" ничего особо нет? тогда да, десериализацию можно. Но практика показывает что люди очень любят в сущностях миксовать штуки которые можно было бы захэндлить просто с теми которые требуют пристального контроля

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

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

ну тут вопрос не в том принимать реквест или мэпить на что-то. Тут вопрос мэпить это на сущность или на DTO через десериализацию. В описанном тобой варианте я мэплю на DTO и принимаю ее на вход в контроллер. Причем до мэппинга я делаю валидацию самого запроса, что позволяет мне в последствии делать мэппинг не совсем 1:1

ну тут вопрос не в том принимать реквест или мэпить на что-то. Тут вопрос мэпить это на сущность или на DTO через десериализацию. В описанном тобой варианте я мэплю на DTO и принимаю ее на вход в контроллер. Причем до мэппинга я делаю валидацию самого запроса, что позволяет мне в последствии делать мэппинг не совсем 1:1

именно запроса, не DTO?

а, окей, после "правки" понял

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

резонно. но выходит если мэппинг всегда 1 к 1, то получается +- тоже самое.

резонно. но выходит если мэппинг всегда 1 к 1, то получается +- тоже самое.

если 1:1 то да, примерно то же самое. в этом случае можешь валидировать DTO

ну а если у тебя запрос и табличка в базе 1:1 и между принял http запрос и записал в базу ничего нет (может проверка прав разве что) - то можно и на сущность

но последнее часто превращается в "а вот с двумя полями из 10-ти все не так просто"

или внезапно всплывает необходимость делать ревизии

как-то был проектик который на скорую руку так вот сделали - типа с jms serializer и прочей сатаной. Быстро, просто... проект сдали а через 2 года вдруг клиент поднакопил деньжат и решил допилить, и все эти JMS потом сильно боком вышли

ну а если у тебя запрос и табличка в базе 1:1 и между принял http запрос и записал в базу ничего нет (может проверка прав разве что) - то можно и на сущность

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

как-то был проектик который на скорую руку так вот сделали - типа с jms serializer и прочей сатаной. Быстро, просто... проект сдали а через 2 года вдруг клиент поднакопил деньжат и решил допилить, и все эти JMS потом сильно боком вышли

о, уже у которого человека в этом чате спрашиваю. что не так с jms?

как-то был проектик который на скорую руку так вот сделали - типа с jms serializer и прочей сатаной. Быстро, просто... проект сдали а через 2 года вдруг клиент поднакопил деньжат и решил допилить, и все эти JMS потом сильно боком вышли

Как реализовали в итоге? я переписывал стандартный симфони сериалайзер как то

о, уже у которого человека в этом чате спрашиваю. что не так с jms?

основная проблема jms - сырость. Года 3 проект просто не развивался, баги не фиксились. Не знаю как сейчас. Ну и вторая проблема, в сравнении с тем же symfony/serializer - изменение данных, то есть если тебе надо данные впихнуть в имеющуся сущность тебе нельзя просто взять и дать нужный объект, тебе надо писать всякие листенеры и прочий булшит. Да и если тебе надо как-то "по особому" захэндлить десериализацию просто написать хэндлер для типа ты не сможешь. Ну то есть оно не сложно но почти всегда заканчивается тем что всплывает логика на ивентах.

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

Как реализовали в итоге? я переписывал стандартный симфони сериалайзер как то

не знаю зачем его переписывать. А реализовали очень просто - выкинули jms serializer)

оставили его только там где логика не нужна была

где-то две трети пришлось полностью переделать

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

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

что переписывать и зачем?

symfony serializer отвечает за очень простую сферу дейтельности - принять данные на вход и выплюнуть на выход результат.

основная проблема jms - сырость. Года 3 проект просто не развивался, баги не фиксились. Не знаю как сейчас. Ну и вторая проблема, в сравнении с тем же symfony/serializer - изменение данных, то есть если тебе надо данные впихнуть в имеющуся сущность тебе нельзя просто взять и дать нужный объект, тебе надо писать всякие листенеры и прочий булшит. Да и если тебе надо как-то "по особому" захэндлить десериализацию просто написать хэндлер для типа ты не сможешь. Ну то есть оно не сложно но почти всегда заканчивается тем что всплывает логика на ивентах.

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

тупая трансформация. Писать кастомные хэндлеры - это да, это нужно. А вот переписывать сам сериалайзер - это явно что-то не то

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

ну да, это типичная проблема, смешание зон ответственности в сущностях

Нет не правильно выразился, переписывался get_set normaliser и denormalizer там были еще какие то костыли в сущностях

Через компайлер подменялся класс и делалась вся магия трансформации

у меня была задумка для таких - сделать отдельный гидратор + кодогенератор который был из сущностей генерил DTO 1:1 тупо что бы можно было все UI специфичные штуки туда запихнуть ну и что бы эти сущности на UoW не влияли (ну и быстрее))

Нет не правильно выразился, переписывался get_set normaliser и denormalizer там были еще какие то костыли в сущностях

ну так это другое дело)

Было давно

Надо в код лезть, лень

ну так это другое дело)

Но нормализаторы и денормализаторы часть сериалайзера а значит все же переписывал сериалайзер :)

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

ну и еще мой PR в доктрину который позволял более удобно работать с SELECT new SomeDTO перенесли на 3-ю версию так что...

Но нормализаторы и денормализаторы часть сериалайзера а значит все же переписывал сериалайзер :)

нет, ты просто реализовал свои нормалайзеры и денормалайзеры. Это то для чего симфони сериалайзер и создавался.

Ок :)

есть огромная разница, так как то что ты использовал - это родные extension points компонента. Вот если бы компонент не позволял тебе это сделать - тогда "переписывал"

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

они уже сделали так что бы можно было из коробки любой объект подкладывать одной строчкой (или параметром) для десиариализации?

без листенеров и как в symfony/serializer

они уже сделали так что бы можно было из коробки любой объект подкладывать одной строчкой (или параметром) для десиариализации?

/me не совсем понял, ушёл искать пример на симфоневском сериализаторе

$person = $serializer->deserialize($data, Person::class, 'xml', [ 'object_to_populate' => $person ]);

$person = $serializer->deserialize($data, Person::class, 'xml', [ 'object_to_populate' => $person ]);

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

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

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

p.s. если валидировать запрос а не результат мэппинга - то можно закрыть глаза на многое)

$person = $serializer->deserialize($data, Person::class, 'xml', [ 'object_to_populate' => $person ]);

подтверждаю, что jms - это тупик. склоняю на транзит кастомера этого дела на ламповый symfony/serializer.

Может кто подскажет как правильно настроить READ_WRITE cache mode в доктрине ?

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

это только валидация ввода? сами сущности еще могут себя валидировать и не давать создать их в невалидном состоянии? или в целом вся валидация уходит туда?

Подскажите, плиз. Хочу где то указать, что такие то контроллеры имеют такой-то prefix в route. Думал прокатит как в джава сделать свой (родительский) контроллер, а там прописать у него базовый роут. Но не прокатило. Как лучше такое настраивать, чтобы в каждом файле не указывать полный путь Route?

это только валидация ввода? сами сущности еще могут себя валидировать и не давать создать их в невалидном состоянии? или в целом вся валидация уходит туда?

есть валидация ввода и есть валидация бизнес ограничений

Подскажите, плиз. Хочу где то указать, что такие то контроллеры имеют такой-то prefix в route. Думал прокатит как в джава сделать свой (родительский) контроллер, а там прописать у него базовый роут. Но не прокатило. Как лучше такое настраивать, чтобы в каждом файле не указывать полный путь Route?

https://symfony.com/blog/new-in-symfony-4-1-prefix-imported-route-names

https://symfony.com/blog/new-in-symfony-4-1-prefix-imported-route-names

4.1 пока нет в стабильной ветке

4.1 пока нет в стабильной ветке

суть та же в routing.yml указывешь что-то типа(для 3.4 версии): route_name: resource: '@AppBundle/Resources/config/routing/routing/routesWithPrefix.yml' prefix: /prefix а в routesWithPrefix.yml перечисляешь свои контроллеры и экшены, они уже будут с префиксами

суть та же в routing.yml указывешь что-то типа(для 3.4 версии): route_name: resource: '@AppBundle/Resources/config/routing/routing/routesWithPrefix.yml' prefix: /prefix а в routesWithPrefix.yml перечисляешь свои контроллеры и экшены, они уже будут с префиксами

ну так можно. только придется каждый контроллер ручками прописывать. я сейчас думаю как сгруппировано это делать. к примеру по типу контроллера определять и т.п.

или по namespace

resource: "@App/Controller/MyController.php" prefix: "/my"

можно так

можно весь неймспейс зарегать

resource: "@App/Controller/MyController.php" prefix: "/my"

и наследованные контроллеры тоже будут придерживаться придерживаться этих правил?

ERROR: S client not available

не уверен, не пользуюсь наследованием

Кто-то находил решение для отключения авто выравнивания в Configuration классах штормом?

Кто-то находил решение для отключения авто выравнивания в Configuration классах штормом?

поясни

кто-нибудь юзал arangodb?

Тема ок, можно линк ?

кто-нибудь юзал arangodb?

пока нет но планирую сравнить ее с orientdb

кто-нибудь юзал arangodb?

смотря для чего? я игрался с графами, но не было каких-то специфических задач, чтобы сравнить с orientdb очень или той же монгой. скажу, что год назад не было нормально клиента для работы, максимум коннекшен и дальше все запросы руками

если будете что-то педалить, то посмотрите на актуальность и функциональность пакетов

@fes0r Захотел попробовать твой бандл, RequestObjects ... но у меня появилось 2 проблемы. 1. Почему-то при валидном реквесте выдает ошибку, что поля нет, хотя оно есть 2. Как сделать вывод "path" вместо [name] просто name? Почти все взял с примера https://gist.github.com/misterx/6a2cf4387b0f844e722922dc8780f067#file-request-json

@fes0r Захотел попробовать твой бандл, RequestObjects ... но у меня появилось 2 проблемы. 1. Почему-то при валидном реквесте выдает ошибку, что поля нет, хотя оно есть 2. Как сделать вывод "path" вместо [name] просто name? Почти все взял с примера https://gist.github.com/misterx/6a2cf4387b0f844e722922dc8780f067#file-request-json

1. Снимается, как глупое )

@fes0r Захотел попробовать твой бандл, RequestObjects ... но у меня появилось 2 проблемы. 1. Почему-то при валидном реквесте выдает ошибку, что поля нет, хотя оно есть 2. Как сделать вывод "path" вместо [name] просто name? Почти все взял с примера https://gist.github.com/misterx/6a2cf4387b0f844e722922dc8780f067#file-request-json

https://github.com/fesor/request-objects/blob/master/README.md#handling-validation-errors

https://github.com/fesor/request-objects/blob/master/README.md#handling-validation-errors

Я это сделал, https://gist.github.com/misterx/6a2cf4387b0f844e722922dc8780f067, но getPropertyPath вместо name возвращает [name], есть ли возможность от этого избавиться?

это парафия symfony/validator

это парафия symfony/validator

Угу, это из-за Collection, но возможно кто-то юзал, и как-то это исправлял

Угу, это из-за Collection, но возможно кто-то юзал, и как-то это исправлял

ох, я как-то загонялся и конвертировал это дело в json pointer

но по факту профита от этого небыло

Привет гайз, вакансия на удаленку, Fullstack разработчик на долгосрочный проект #php #js #удаленка #фултайм ставка 80-100к Требования: Уметь кроссбраузерно верстать HTML5/CSS3, понимать XML; Знать и применять JavaScript (jQuery); Уметь работать с методом запросов AJAX, разбираться в JSON; Отлично знать минимум PHP5, но лучше PHP7; ООП - понимать, применять, любить; MySQL, PostgreSQL - Уметь создавать сложные запросы к БД, оптимизировать их, строить связи между таблицами; Понимать как работают ключи и индексы; Понимать MVC фреймворки. Опыт работы с Symfony 3 приветствуется; Базовые навыки администрирования UNIX-систем; Уметь правильно работать с репозиториями Git, SVN; Уметь писать тесты к коду, и использовать их; Условия: Удаленная работа над одним проектом (не клиентские проекты) Полный рабочий день, 8 часов, быть доступным для связи при необходимости в рабочее время (Скайп, тг, почта) Зп: 80-100к на руки, от опыта и возможностей @Mari_et

/spam

черт, когда кликаешь на это дерьмо мышкой - оно дублируется .... хотел зарепортить спам и сам стал спамером :'(

А как репортить я тоже за дублировал :)

Админы должны просто удалить по идее

ох, я как-то загонялся и конвертировал это дело в json pointer

Тоесть, никак =) Ну что б красиво )

Админы должны просто удалить по идее

ну у нас тут вроде бы не банят вакансии...

но по факту профита от этого небыло

А как с фронтом решил проблему? По факту отправили поле с одним именем, а ошибку получили с другим. Или там какой-то костыль?

вообще это правило можно пересмотреть

А как с фронтом решил проблему? По факту отправили поле с одним именем, а ошибку получили с другим. Или там какой-то костыль?

это по сути только для разработки надо - в продакшене подобных ошибок быть не должно

вообще это правило можно пересмотреть

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