а если во втором запросе в select указать m.*, cm.*, mc.* ?

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

а если во втором запросе в select указать m.*, cm.*, mc.* ?

Ничего не меняется

Почему доктрина возвращает три отдельных результата? SELECT m, cm, mc FROM AppBundle:Meal m JOIN AppBundle:CategoryMeal cm WITH m = cm.meal JOIN AppBundle:MenuCategory mc WITH mc = cm.category В то время как чистый SQL запрос возвращает 1 результат, т.е. связывает результаты, как и положено SELECT * FROM meal m JOIN category_meal cm ON m.id = cm.meal_id JOIN menu_category mc ON mc.id = cm.category_id

getArrayResult

getArrayResult

То есть так я не должен делать?

должен так

должен так

Так и делаю

показал бы все что делаешь

показал бы все что делаешь

Я упростил код, сейчас весь запрос скину

Тогда тебе нужен свой гидратор

Иначе будет возвращать отдельно все

Тогда тебе нужен свой гидратор

Неужели доктриновские умельцы не предусмотрели объединения в одну строку?)

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

Как он тебе смержит поля типа id?

Как он тебе смержит поля типа id?

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

но ведь доктрина возвращает массив обьектов с зависимостями

но ведь доктрина возвращает массив обьектов с зависимостями

getArrayResult()

getRawSQLBlyatArray() вот такого метода нет что ли там?

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

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

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

Куда копать? Я не знаю, что значит "кастомный гидратор"

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

Всё, нашел

Что то слишком overpowered для такой простой задачи, тогда уж лучше просто чистый SQL запрос буду делать

http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/dql-doctrine-query-language.html#custom-hydration-modes

Для простого запроса ты указываешь конкретные поля

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

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

Я еще не знаю, и именно поэтому стараюсь делать все инструментами предоставляемыми доктриной, использовать find, findBy, если этого недостаточно, пишу DQL запросы, если уже и на DQL не могу, то пишу на SQL с мыслью, что позже мне это выйдет боком

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

Вот переписал на чистом SQL. Вопрос: есть ли в данном случае какие нибудь преимущества в использовании DQL синтаксиса?

кто мне навскидку скажет в чем разница ParamConverter и ArgumentValueResolver?

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

https://github.com/sensiolabs/SensioFrameworkExtraBundle/pull/436 а вот и ишью на выпиливание

наконец-то нас заметили

Js забыли

это лига хипстеров

такой вопрос, есть ли годные мануалы как реализовать SSE в связке nginx + symfony?

вряд ли

Лучше не париться и запилить вебсокет?

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

https://github.com/GeniusesOfSymfony/WebSocketBundle — есть вот такой бандл для WS.

всем привет, кто то подскажет как настроить авторизацию FOS используя 2 разные таблицы, (разные провайдеры)? в доках есть описание если реализовывать авторизацию с несколькими провайдерами без ФОС http://symfony.com/doc/current/security/multiple_user_providers.html

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

Оказалось, чтобы реализовать sse надо всего лишь https://gist.github.com/alg3rd/a5db1e46ea4610070f248912986828e1

Даже вебсервер не надо настраивать

только один воркер всегда этим занят)

/akunamatata

всем привет, кто то подскажет как настроить авторизацию FOS используя 2 разные таблицы, (разные провайдеры)? в доках есть описание если реализовывать авторизацию с несколькими провайдерами без ФОС http://symfony.com/doc/current/security/multiple_user_providers.html

Пользователь должен искаться в двух таблицах сразу?

var_dump(gettype(ItemType::class)); $form = $this->createForm(ItemType::class, $item);

не на эту строку ругается

Как не на эту?

Думал шторм не сохранил

Открыл с консоли, там ::class

ну там же какойто TariffType

полный стек покажи

ОУЧ

Блина

Это отсутствие сна

Спасибо, тогда понятно где туплю

:)

ERROR: S client not available

8 мартааа

спать надо

Или подарки заранее покупать

Пользователь должен искаться в двух таблицах сразу?

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

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

А можно узнать, зачем тебе понадобилось две разные таблицы?

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

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

Я сам в данный момент работаю над проектом, где разные типы пользователей, тоже использую FOSUserBundle.

Ты можешь создать три сущности: 1) базовую User, которая содержит общую информацию, которая есть у всех пользователей, независимо от типа 2) Customer (например). Эта сущность содержит специфическую для этого пользователя информацию 3) Admin - также, содержит специфическую для админа информацию. Между сущностями делаешь связи oneToOne User <- one-to-one -> Customer User <- one-to-one -> Admin Когда пользователь регистрируется, создается User и к нему привязывается нужная тебе сущность, либо Customer либо Admin

Сущности User можешь добавить поле type

При регистрации добавляешь создаваемому юзеру роль

да такой алгоритм у меня уже есть и БД тод это затачивал, а скажи пожалуста какие в таком подходе преимущества перед раздельным хранением? по ряду причин мне не хочется смешивать эти типы пользователей, вот и интересуюсь как

да такой алгоритм у меня уже есть и БД тод это затачивал, а скажи пожалуста какие в таком подходе преимущества перед раздельным хранением? по ряду причин мне не хочется смешивать эти типы пользователей, вот и интересуюсь как

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

Есть еще бандл, который расширяет FOSUserBundle

Как раз для разного типа пользователей

https://github.com/PUGX/PUGXMultiUserBundle

Но я им не пользовался

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

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

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

Ты можешь создать три сущности: 1) базовую User, которая содержит общую информацию, которая есть у всех пользователей, независимо от типа 2) Customer (например). Эта сущность содержит специфическую для этого пользователя информацию 3) Admin - также, содержит специфическую для админа информацию. Между сущностями делаешь связи oneToOne User <- one-to-one -> Customer User <- one-to-one -> Admin Когда пользователь регистрируется, создается User и к нему привязывается нужная тебе сущность, либо Customer либо Admin

да, так это и делается

Сергей а скажи пожалуста какие в таком подходе преимущества перед раздельным хранением?

да такой алгоритм у меня уже есть и БД тод это затачивал, а скажи пожалуста какие в таком подходе преимущества перед раздельным хранением? по ряду причин мне не хочется смешивать эти типы пользователей, вот и интересуюсь как

А какие преимущества в раздельном хранении? Может стоит вопрос так ставить?)

у тебя в users хранятся только креденшиалы и роли. вся остальная инфа хранится в отдельных таблицах

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

А какие преимущества в раздельном хранении? Может стоит вопрос так ставить?)

предполагаю будет меньше join которых будет предостаточно

предполагаю будет меньше join которых будет предостаточно

one-to-one join'ы не страшная штука

one-to-one как раз таки самые страшные)

от них не избавится с помощью lazy

one-to-one как раз таки самые страшные)

Почему же?

их всегда как eager будет тянуть

их всегда как eager будет тянуть

Пусть тянет, они и должны тянуться. Много ресурсов что ли требуется для этого