да, я рассматриваю весь этот чейн как цепочку адаптеров между http и приложением, мне так проще

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

кто мне скажет, есть в доке такой момент http://symfony.com/doc/current/doctrine/associations.html Relationships and Proxy Classes Решил посмотреть у себя, а правда ли там прокси. И нифига

а не, норм. Proxies\__CG__\AppBundle\Entity\Report

кто как решает вопрос data migrations? через метод postUp обычных миграций? или через обычные команды?

Смотря какая задача

К примеру когда создается юзеров таблица, надо сделать сразу postUp (админа добавить например). А если добавить какие-то левые данные генерю новую миграцию.

кто как шифрует данные в куках?

данные в куках я шифрую в сессии)

а если данные надо долго держать?

вешать сессионную куку с большим сроком хранения?

К примеру когда создается юзеров таблица, надо сделать сразу postUp (админа добавить например). А если добавить какие-то левые данные генерю новую миграцию.

добавлять данные через миграции не круто

команды/отдельные фикстуры

вешать сессионную куку с большим сроком хранения?

Хранить кучу сессий?

Хранить кучу сессий?

если их не миллион с мегабайтными данными, то почему бы и нет.

зачем мне хранить кучу всех сессий для маленькой строки, которую используют 20% пользователей?

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

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

да ничего особо страшного

Например в симфони remember me шифруется в куках

через base64_encode

тогда почему их не хранить в открытом виде?) но если хочется зашифровать -- openssl_encrypt() / openssl_decrypt()

Угу сделал с их помощью

К примеру когда создается юзеров таблица, надо сделать сразу postUp (админа добавить например). А если добавить какие-то левые данные генерю новую миграцию.

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

@fesor призываю на обсуждение)

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

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

окей, спасибо где-то так и думал

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

это как? типа для выборки один набор сервисов, а для вставки другой?

это как? типа для выборки один набор сервисов, а для вставки другой?

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

хотя с другой стороны - для апдейта тебе может часто даже не нужен будет репозиторий)

@fes0r и зачем так сильно заморачиваться даже если будет одна не нужная зависимость?

@fes0r и зачем так сильно заморачиваться даже если будет одна не нужная зависимость?

что бы контролировать связанность

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

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

1. сделать один листенер который по postflush будет доставать ивенты из сущностей и кидать их в диспетчер событий 2. забить на трейт и сделать класс со статикой (EventStore::remember и EventStore::release) и опять же листенер по postflush

я юзаю первый вариант если что, второй мне нравится все больше и больше

я юзаю первый вариант если что, второй мне нравится все больше и больше

Можно по подробнее про второй вариант, не совсем понимаю

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

EventStore::remember(UserRegisteredEvent::occure($this->id, $this->profile));

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

понял, спасибо большое

В доктрине есть список запрещенных имен, которые нельзя использовать в qb алиасах?

проверь)

проверь)

Ну теперь придется)

ну она никак об этом не скажет, скажет фатал при запросе)

as count нельзя)

Просто я использую зарезервированное имя mysql group для qb. А как заэкранировать что-то не могу найти

group попробуй

пробовал. \`\` \`\` и \` \` и {}

Нифига

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

таблички можно апострофом экранировать так

в аннотации доктрины

привет, вопрос куды положить такой код, вот в репозиториях есть методы типа findByField и часто в слоях выше приходится использовать этот метод. Если он возвращает null нужно кидать что-то типа NotFoundHttpException. И вот такой код напрашивается на дублирование, корректно ли сделать в репах методы типа getByField, которые будут либо возвращать код либо кидать исключение? Или как лучше поступить?

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

null репозиторий может возвращать?

если не найдены результаты

можно все. но вообще не должен

нежелательно но можно. назовем это так

а где про это почитать?

ну погугли repository pattern return null

Exception вот не понимаю почему там должен быть. ведь это нормальное поведение что нет найденных результатов

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

А типы исключений как в таком случае лучше организовать? Просто кастомное исключение типа RepositotyNotFoundException ?

Почему тогда стандартный findOneBy не падает с exception-ом?

Exception вот не понимаю почему там должен быть. ведь это нормальное поведение что нет найденных результатов

на код надо смотреть не с позиции "вот я смотрю на нутро репозитория" а с позиции "вот я смторю как это используется и тут null не катит

find - это либо нашло, либо исключение get - это либо нашло, либо нулл такое именование

то есть банально если у тебя есть метод getSomething и везде где оно юзается "низя" что бы был null - то логично что бы твоей метод этого объекта соответствовал этому

find - это либо нашло, либо исключение get - это либо нашло, либо нулл такое именование

лучше по ICP загоняться

ой не, я пошел работать

нежели выдумывать какие-то там конвенции

что то найду описания что нельзя null и обязано Exception

есть ссылка?

Почему тогда стандартный findOneBy не падает с exception-ом?

потому что он стандартный. Я к примеру "стандартные" доктриновские репки в свои заворачиваю с моими чистыми интерфейсами

что то найду описания что нельзя null и обязано Exception

да делай что хочешь, просто повторюсь

одна из основныз ошибок при проектировании интерфейсов - проектирование в отрыве от того как они юзаются

чувак ты чего обижаешься? я тебе не противоречил, я ищу инфу

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

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

доктриновские - это последнее

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

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

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

если не все - лучше сделать 2 метода

идея - уменьшение количества if-ов в коде

ну по логике вещей ожидают коллекцию данных? она не найдена, а тебе в ответ «извини, что то пошло не так». Или я эксепшены неверно понима/

нет, стой

если ничего не найдено у тебя пустая коллекция но никак не null

у тебя пустая коллекция

так, уже лучше

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

речь про find объекта

понял

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

но идея все та же - проектируй сверху вниз а не снизу вверх, не подгоняй код под репозиторий, подгоняй репозиторий под код

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

найти тоже может приводить к исключению

>find - найти, т.е. ты не уверен, что такие данные есть, а просто ищешь следуя здравой логике тоже так кажется

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