Вложенные данные. Например: пользователь с его ролями и офисами. Хотелось доставать все сразу, а не кучей запросов. Решил пока тем, что в резолвере получаю инфу о структуре запрошенных данных и если нужны связи - тяну их сразу с пользователями

ну это решается без джойнов простым where in запросом и склейкой на стороне приложения

я все же думаю что учитывать что запросили - сильно усложняет и в целом первое время точно можно не заморачиваться

а потом - делать 2-3 запроса а не 1+N+M

Типо имеешь в виду запросить пользователей, потом отдельно все роли для этих пользователей и тогда склеить?

тип того

Говорят есть какие то проблемы с http cache, по сравнению с rest

тип того

Думал о таком тоже, но как-то подсунуть джоин вышло попроще... Поэтому оставил пока так

Говорят есть какие то проблемы с http cache, по сравнению с rest

нет http cache, вот и вся проблема)

ну это решается без джойнов простым where in запросом и склейкой на стороне приложения

Но тебе же всеравно надо понять что запрашивали роли/офисы. Как ты это делаешь чтобы wherein бахнуть?

Но тебе же всеравно надо понять что запрашивали роли/офисы. Как ты это делаешь чтобы wherein бахнуть?

отдельный ресолвер на филд

Так если 100 пользователей - он разве не пойдет 100 раз в резолвер Филда?

Если нет, то видимо я не до конца понял как резолвер Филда работает...

нет http cache, вот и вся проблема)

Тесты не упадут если... ?))

Тесты не упадут если... ?))

чта?

чта?

Что значит нет http cache?

Так если 100 пользователей - он разве не пойдет 100 раз в резолвер Филда?

пойдет, но там вступают в игру всякие промисы и т.д.

Ну вот, так и знал. Даталоадеры... Чет они мне вообще не зашли

Что значит нет http cache?

ну то и значит что http cache бесполезен и тебе надо делать свой. Если хочешь можешь взять relay + уникальные идентификаторы и будет у тебя простой и удобный кэш

есть еще persisted queries подход

тогда можно пользоваться http кэшем

Одно что подкупает в промисах, что резолвер Филда можно будет в пару других вложить и не парится. С моим подходом так не выйдет - нужно в каждом филде где могут быть вложенности - контролировать это. Так что возможно я к этому прийду..

Вложенные данные. Например: пользователь с его ролями и офисами. Хотелось доставать все сразу, а не кучей запросов. Решил пока тем, что в резолвере получаю инфу о структуре запрошенных данных и если нужны связи - тяну их сразу с пользователями

вообще есть еще такая мысль... 1. на первое время N+1 запросов вообще не проблема, это можно оптимизировать уже когда ты поймешь за какими данными к тебе ходят. Если данные о ролях и офисах нужны всегда или в большинстве случаев - делай себе джойны и не парься. Или дата лоадеры. Но в начале можно тупо делать кучу запросов. Это нормально. 2. если бы ты пилил REST API у тебя эти данные отдавались бы всегда, вот вообще всегда. И возможно просто ты бы сделал две разные схемы запросов по месту (где эти данные не нужны).

так?

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

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

Ну впринципе да =) Но думаю ничего сверх ужасного в текущем костыле нет - он сводится к 3 строкам. План такой: начнет мешать => разбираюсь с даталоадерами => дописываю филд резолверы => грохаю 2 строки.

кто как дружит свои апишки со сваггером?

кто как дружит свои апишки со сваггером?

никак)

вообще не юзаешь?

ай не, raml/api bluerptint как-то поинтереснее... сваггер более-менее когда у тебя оно из кода генерится

я просто продолжаю свою тему с двусторонней валидацией хочется же еще и какой-то гуй для апишки на будущее

и возникла мысль описать jjson схемами входящие данные для ендпоинтов, а в сваггере эти схемы подтягивать

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

или ты не о том?

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

не, не про тестирование

валидация по одинаковой схеме на фронте и на бекенде

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

а что с ней?

что с конфигой загрузки?

а что с ней?

В symfony4 вижу doctrine_migrations.yaml, но не могу же я в него добавить путь для миграций бандла.

symfony flex же)

В symfony4 вижу doctrine_migrations.yaml, но не могу же я в него добавить путь для миграций бандла.

тварь ты дрожащая или право имеешь?

doctrine_migrations: dir_name: '%kernel.project_dir%/src/Migrations' namespace: DoctrineMigrations

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

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

dir_name это и есть путь

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

а зачем там формы? это ж не "валидация", это бизнес логика

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

"если у поста удалить последний тег, то он станет неопубликованным" - это не валидация

что-то типа dry-run

doctrine_migrations: dir_name: '%kernel.project_dir%/src/Migrations' namespace: DoctrineMigrations

Да, но ведь это для проекта в целом, а хотелось бы этот конфиг не трогать и что-бы для App был путь и namespace, но и сделать такой-же конфиг для бандла.

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

post->untag(); untag(tag){ tags->remove(tag) if(empty(tags){ status = unpublished } }

обычно такие штуки прямо на клиенте пилят

"если у поста удалить последний тег, то он станет неопубликованным" - это не валидация

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

клиенту доверять низзя, для апишечки это тоже надо

Да, но ведь это для проекта в целом, а хотелось бы этот конфиг не трогать и что-бы для App был путь и namespace, но и сделать такой-же конфиг для бандла.

чет я не понял задачи) 2 разных папки миграции?

чет я не понял задачи) 2 разных папки миграции?

Ага

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

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

Ага

ты типа миграции для разных бандлов херачишь?

post->untag(); untag(tag){ tags->remove(tag) if(empty(tags){ status = unpublished } }

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

в этом же нет смысла - миграции одни на все приложение

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

да, это бизнес логика. От отсутствия тегов пост становится необпубликованным, но валидным

ты типа миграции для разных бандлов херачишь?

Типо думаю сделать.

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

ну так покажи))

в этом же нет смысла - миграции одни на все приложение

Почему бандл не может содержать какие-то свои миграции?

ну так покажи))

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

Почему бандл не может содержать какие-то свои миграции?

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

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

в 99% случаев это обрабатывается на клиенте js-ом

ERROR: S client not available

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

так как итоговый результат выполнения этих правил отличается

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

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

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

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

можно, но тогда надо будет для твоего бандла регистрировать отдельный entity manager и тогда можно

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

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

ну так так и делай. На вход данные - на выход стрим действий, после подтверждения действий они применяются

но проще "узнать" что там с клиентом и ручаться за него

можно, но тогда надо будет для твоего бандла регистрировать отдельный entity manager и тогда можно

Где можно за это почитать?

но проще "узнать" что там с клиентом и ручаться за него

когда пилишь апи - это иногда невозможно)

Где можно за это почитать?

погугли doctrine migrations multiple entity managers

погугли doctrine migrations multiple entity managers

thanks

когда пилишь апи - это иногда невозможно)

ну я тебе описал как бы я это делал - на вход данные - на выход коллекций действий с данными. никаких сайд эффектов. потом после конфирмации действия просто применяются

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

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

тут надо чуть больше знать а у меня нет времени

ок, спасибо)

+ тебе за это не платят)))

поудалял из группы лишние файлы, оставил только книжки

и вот вам еще бонус

@fes0r как тебе вариант использования генераторов? https://gist.github.com/grachevko/59662741ed2984f564364391c5230dfe

Не знал, что без вызова Generator::current() или Generator::next() код до yield не выполняется.

еще send можно вызвать)

А send что делает?

Передает значение в генератор

ээ

Не знал, что без вызова Generator::current() или Generator::next() код до yield не выполняется.

в этом их суть. Ты можешь прервать выполнение или из вызывающей стороны отправить значение

$foo = yield; // заполни $foo через send

Я думал прерывание происходит при достижении yield.

не

если в функции есть yield