Я что-то запутался, как с этим жить

Постоянно какие то проблемы

а что не так?

просто хост указываешь в конфиге же

У нас приложение запускается в разных средах. dev, stage, rc, prod. В каждом из них хосты разные. Базовый хост передаётся через environment

Хотел сделать, чтобы любой хост целиком можно было подменить через env. Но выяснислось следующее https://github.com/symfony/symfony/commit/a931002ca25b6e3c127dc4df027040a33e24b672

Что в итоге породило вот такую ересь env(ADMIN_HOST): 'admin.%env(BASE_HOST)%' env(CONTENT_HOST): 'content.%env(BASE_HOST)%' env(API_HOST): 'api.%env(BASE_HOST)%' env(WWW_HOST): 'www.%env(BASE_HOST)%' admin_host: '%env(ADMIN_HOST)%' content_host: '%env(CONTENT_HOST)%' api_host: '%env(API_HOST)%' www_host: '%env(WWW_HOST)%'

отдельный конфиг с параметрами на каждое окружение, не?

Выглядит так себе, конечно, но видали хаки и пострашнее существенно

отдельный конфиг с параметрами на каждое окружение, не?

в stage BASE_HOST динамический, и как я эти конфиги буду грузить? Сообщать приложению, в каком месте оно сейчас запущено?

ну так у тебя в корне есть app.php, есть app_dev.php, таким же образом делаешь app_stage.php с указанием env, а на сервере просто нужный путь кормишь нжинксу

Приложение знает окружения dev, test и prod. А кто, где и для каких целей его стартует ему знать не нужно. Тем более иметь для этого отдельные конфиги.

У меня есть index.php

В котором if ($debug = filter_var(getenv('SYMFONY_DEBUG'), FILTER_VALIDATE_BOOLEAN)) { Debug::enable(); } $kernel = new App\Kernel(getenv('SYMFONY_ENV'), $debug);

посмотри в AppKernel, как симфони грузит нужный конфиг в зависимости от окружения

а что не так?

В api-platform тоже косяк был, она для подзапросов создаёт свой RequestContext, куда не передаёт host. В итоге подзапрос уходит в 404

кто-нибудь пробовал использовать api-platform без доктрины?

Пока нет, но чую скоро будем пробовать

Хотя скорее всего будем GraphQL пилить вместо реста

Хотя скорее всего будем GraphQL пилить вместо реста

я так уже пол года говорю(

но все никак не могу заставить чуваков поресерчить и разобраться

У нас сейчас связка api-platform -> graphql (node.js) -> react

Гемора больше чем толку, почти выпилили этот огород. Как дойдёт дело до мобильного приложения, думаю GraphQLBundle поставить. Правда говорят, что ещё сыровата реализация на php

Гемора больше чем толку, почти выпилили этот огород. Как дойдёт дело до мобильного приложения, думаю GraphQLBundle поставить. Правда говорят, что ещё сыровата реализация на php

есть два бандла, одно - уг полное (там где схема в yaml)

ну то есть как, это вкусовщина на самом деле

но меня подбешивает

мне больше нравится тот где для каждой схемы отдельные классы создаются

мне тоже но не нравится как сделаны ресолверы

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

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

мне не нравится идея инджектить что либо в описание типа.

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

Просто теже резолверы могут иметь зависимости. Инжектить их?

В качестве резолвера оставлять namespace, и где то при компиляции туда подставлять этот сервис из контейнера?

ну такое

не уверен

еще вопрос - eager подгрузка данных всякая

надо этот вопрос еще поресерчить. Я для своего проекта кастыль писал

https://tideways.io/profiler/blog/5-doctrine-orm-performance-traps-you-should-avoid так до конца и не понял что такого плохого в join? 2й пункт

может кто популярно объяснить?

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

https://tideways.io/profiler/blog/5-doctrine-orm-performance-traps-you-should-avoid так до конца и не понял что такого плохого в join? 2й пункт

https://ocramius.github.io/blog/doctrine-orm-optimization-hydration/

концептуальный вопрос ... как назвать rest api, которое блокирует юзера? ... POST|PUT /users/blocked ... PATCH /users/%userId% {"status": "blocked"} ... PATCH /users/%userId% {"action": "block"} ... чо-т все хрень какая-то )

POST /users/1/block окейно как по мне

blocked только

и PATCH

имхо, тут логичнее всего PATCH /users/id {'action':block}

Тут по проекту уже.

если делать users/1/block, то вроде как не rest'ово, а rpc-шно ... если {action: block} в теле патча, то придется разруливать разные экшены на уровне контроллера, а не на уровне url ... post /users/1/blocked выглядит как какой-то хак )) ... думал, мб есть какой-то устоявшийся подход на эту тему

Где то видел решение вида POST /users/1/blocks

сейчас используем как правило хак вида POST /users/blocked {"userId": 123345} ... вроде как создаётся новый ресурс в коллекции заблокированных пользователей

@fes0r стригерю тебя на rest))

сейчас используем как правило хак вида POST /users/blocked {"userId": 123345} ... вроде как создаётся новый ресурс в коллекции заблокированных пользователей

ну вот в POST /users/1/blocks аналогичная логика, типа в коллекцию блокировок пользователя добавляешь новую блокировку

в твиттере POST /blocks/create

POST /users/report_spam

POST /mutes/users/create

подход "не париться" - самый правильный ))

видимо)

подход "не париться" - самый правильный ))

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

Ктото использует https://github.com/Happyr/Doctrine-Specification ? Как вы обходите то, что при использовании Spec::leftJoin / join он не вытаскивает сразу то, что джойнишь, а всеравно подтягивает лениво

@fes0r стригерю тебя на rest))

а че? рест не бывает

рест он же не про формат урлов а про ресурсы

и ограничения которые ты накладываешь на систему

что бы доктрина тянуло не лениво - у тебя это в select должно быть но спецификации не должны влиять на select

в твиттере POST /blocks/create

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

Ктото использует https://github.com/Happyr/Doctrine-Specification ? Как вы обходите то, что при использовании Spec::leftJoin / join он не вытаскивает сразу то, что джойнишь, а всеравно подтягивает лениво

тебе джойн нужен для условий?

иначе можно загнать себя в рамки CRUD

ERROR: S client not available

Хм, зачем они в примерах репозиторий выкинули

Хм, зачем они в примерах репозиторий выкинули

?

не вижу связи

связи нет, это я так, смотрю...

вообще лучше стараться ограничиваться только where.

связи нет, это я так, смотрю...

что бы репозиторий был как коллекция по которой ты можешь match-чить другую коллекцию

это удобненько

ты о чем?

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

а ты о чем?)

я вот об этом return $this->em->getRepository('HappyrRecruitmentBundle:Advert')->match($spec); в сервисе

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

тебе джойн нужен для условий?

нет, вцелом мой кейс в отрезе от проекта можно както так описать: нужно вытащить активных чуваков и название их должности. делаю чтото типа: $users = $usersRepo->match(Spec::andX(Spec::leftJoin('role'), Spec::activeUser())) хотел сделать это за один запрос, а он мне накручивает на каждого чувака еще запрос чтобы role name узнать

я вот об этом return $this->em->getRepository('HappyrRecruitmentBundle:Advert')->match($spec); в сервисе

а почему в документации симфони сущности с сеттерами?) для упрощения

ну вот... учат плохому с самого начала ;)

нет, вцелом мой кейс в отрезе от проекта можно както так описать: нужно вытащить активных чуваков и название их должности. делаю чтото типа: $users = $usersRepo->match(Spec::andX(Spec::leftJoin('role'), Spec::activeUser())) хотел сделать это за один запрос, а он мне накручивает на каждого чувака еще запрос чтобы role name узнать

это не спецификациями надо делать просто

спецификации - это WHERE

а тебе надо SELECT

у них там в спецификации есть метод modify

где можно конечный QueryBuilder менять

там и меняй select

спецификации - это WHERE

так по сути в activeUser и спрятано условие where (допустим status = 'active') $users = $usersRepo->match(Spec::activeUser()) было бы норм? не совсем понимаю твою фразу "тебе надо селект". Я просто хочу пользователей по определенной спецификации , но сразу с ролями, а не чтото конкретное специфичное заселектить. Вроде не так много хочу же.

у них там в спецификации есть метод modify

спс, посмотрю

а тебе надо SELECT

Перечитал еще раз что я написал. Возможно немного плохо описан сам кейс. Я не хочу сразу строковое "название_должности" в результате. Меня вполне устроит если в обьекте User будет полный обьект Role. Единственное что я хочу - чтобы не было дополнительных запросов на получение этого Role по каждому User

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

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

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

ну это разделение ответственности.

Как думаете, загрузка файлов по событию FormEvents::POST_SUBMIT — это норм или лучше всё-таки в контроллере это делать?

define 'загрузка файлов' Если на сервер - так файл и так выгрузился на сервер к этому времени во временную директорию.

Как думаете, загрузка файлов по событию FormEvents::POST_SUBMIT — это норм или лучше всё-таки в контроллере это делать?

В этом событии данные ещё не отвалидированы, надо файлы двигать до валидации?

Главный вопрос: зачем?

Как думаете, загрузка файлов по событию FormEvents::POST_SUBMIT — это норм или лучше всё-таки в контроллере это делать?

Лучше в отдельном сервисе. Его потом можно будет переизпользовать, когда понадобится загрузка файлов по API