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

а закинь мне примерчик

я уж лучше тогда сам задам :х

а закинь мне примерчик

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

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

репортинг вроде норм в отдельный контекст уходит

отчетики всякие

репортинг вроде норм в отдельный контекст уходит

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

и это офигеть как не очевидно и усложняет вопрос))

ну и куча таких вот примеров которые многие (в том числе и я) выделяют в "отдельный контекст"

поиск какой-нибудь, репорты...

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

мне кажется или я вижу здесь признаки rule engines?

ну у меня отчеты получилось это просто апишка с dbal

по крайней мере, что-то схожее есть

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

я так понимаю, что нет

без сущностей

вьюшки и подобное

мне кажется или я вижу здесь признаки rule engines?

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

но я их не очень понимал в то время))

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

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

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

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

у контроллера есть метод forward. Почитай про sub-requests в симфони

вьюшки и подобное

вьюшки неплохое решение....

у контроллера есть метод forward. Почитай про sub-requests в симфони

Спасибо огромное, я просто думал это как internalredirect ))

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

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

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

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

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

Не успел я понять, или понравилось, ибо не довёл до конца. Разбиратся в таком коде выборок себе дороже. А джоинить из трёх таблиц это рухнет как только часть данных "переедет" в другое хранилище с тех или иных причин. Да и знать назв. таблиц нужно (или вести регистр/шарить константами (знать за класс, где взять константу))

Не успел я понять, или понравилось, ибо не довёл до конца. Разбиратся в таком коде выборок себе дороже. А джоинить из трёх таблиц это рухнет как только часть данных "переедет" в другое хранилище с тех или иных причин. Да и знать назв. таблиц нужно (или вести регистр/шарить константами (знать за класс, где взять константу))

> Разбиратся в таком коде выборок себе дороже. ну у меня наоборот упрощение. Сложности там где надо мэпить *-to-many и хочется это делать эффективно... в целом вообще куча сложностей...

но это все можно победить)

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

В шаблонах можно ещё

> Разбиратся в таком коде выборок себе дороже. ну у меня наоборот упрощение. Сложности там где надо мэпить *-to-many и хочется это делать эффективно... в целом вообще куча сложностей...

Я об to many и говорю

Я об to many и говорю

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

оно конечно не так красиво... иногда приходилось лишние id-ки экспоузить...

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

еще одна идея - это "выборки которые занимаются поиском возвращают только ID-ки" и выборки которые выплевывают данные это чисто where in запросы)

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

еще одна идея - это "выборки которые занимаются поиском возвращают только ID-ки" и выборки которые выплевывают данные это чисто where in запросы)

да, можно и так. Пугают разве что "хелперы"

да, можно и так. Пугают разве что "хелперы"

ну это не "хелперы", у меня это дата лоадеры звались)

у кого-то был успешный опыт использования php-pm?

у кого-то был успешный опыт использования php-pm?

в продакшене?) пока нет....

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

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

ну то есть, там и работа с базой была через dbal (sqlite), и чистить особо нечего было...

@fes0r Помнится не давно, ты рассказывал о юзер бандле, типа Credentials отдельно, а инфа о юзере отдельно. Хотел спросить, какие в таком случае есть адекватные методы вытягивания инфы о пользователе, если есть 2-3 типа юзеров? По твоей концепции, для каждого типа пользователя должна быть отдельная сущность. Например Manager, Customer, Admin.

@fes0r Помнится не давно, ты рассказывал о юзер бандле, типа Credentials отдельно, а инфа о юзере отдельно. Хотел спросить, какие в таком случае есть адекватные методы вытягивания инфы о пользователе, если есть 2-3 типа юзеров? По твоей концепции, для каждого типа пользователя должна быть отдельная сущность. Например Manager, Customer, Admin.

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

заказ привязан только к покупателю, продукт только к продавцу и т.д

заказ привязан только к покупателю, продукт только к продавцу и т.д

А производитель?

еще одна идея - это "выборки которые занимаются поиском возвращают только ID-ки" и выборки которые выплевывают данные это чисто where in запросы)

и дублирование этих методов для каждого случая (findNotBanned & findNotBannedIds). Вводить понятие критерии ну нафиг пока

А производитель?

производитель чего?)

Товара)

это пользователь?

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

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

и дублирование этих методов для каждого случая (findNotBanned & findNotBannedIds). Вводить понятие критерии ну нафиг пока

ммм почему дублирование? findNotBanned внутри юзает просто findByIds

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

Ну после логина, как получить Manager или Customer или Admin сущность, не делать же 3 селекта в разные таблицы для проверки ? И как понять кто залогинился? Это же доктриновское наследование придется юзать, но тогда один пользователь может быть только кемто одним.

Ну после логина, как получить Manager или Customer или Admin сущность, не делать же 3 селекта в разные таблицы для проверки ? И как понять кто залогинился? Это же доктриновское наследование придется юзать, но тогда один пользователь может быть только кемто одним.

ты логинишься под определенной ролью нет?

ну или у тебя есть список ролей доступных

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

много вариантов есть)

Кто нибудь настраивал Varnish? Гайдик по поводу кеширования с куками PHPSESSIONID есть у кого?

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

А что это даст? я про связь Credentials->Profile а не Profile->Credentials

А что это даст? я про связь Credentials->Profile а не Profile->Credentials

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

если хочешь "вживую глянуть" как это работает - посмотри на auth0.com

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

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

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

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

ERROR: S client not available

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

Роли получается по любому привязываются к Credentials. Верно?

Роли получается по любому привязываются к Credentials. Верно?

ну все зависит от того как ты делаешь аутентификацию.

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

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

сам понимаешь что все упирается в специфику твоего проекта

ммм почему дублирование? findNotBanned внутри юзает просто findByIds

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

сам понимаешь что все упирается в специфику твоего проекта

Получается, мне нужно какой-то идентификатор что б знать где стянуть профиль. Вопрос простой, есть три типа пользователей, профиль каждого типа в отдельной Entity. После логина мне надо вывести профиль юзера какой залогинился. Вот и у меня вопрос в том ,как узнать в какой табличке его искать. Таким образом получается что в credentials я должен записать тип, что потом найти профиль. Но идея состояла в том, что б в Credentials не менять.

Кто нить брал курсы на udemy? Есть ли смысл по симфони брать

посоветуйте файловый репозиторий на симфу

knp чем не устраивает?

knp чем не устраивает?

кому?

сам понимаешь что все упирается в специфику твоего проекта

Если один тип пользователя, или одна табличка со всеми профилями, проблем какраз нет ) А вот проблема в разделении )

кому?

на вопрос про udemy

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

1 же, инкапсуляция и все такое. Разделение внутри.

На юдеми скидка 90%.

Получается, мне нужно какой-то идентификатор что б знать где стянуть профиль. Вопрос простой, есть три типа пользователей, профиль каждого типа в отдельной Entity. После логина мне надо вывести профиль юзера какой залогинился. Вот и у меня вопрос в том ,как узнать в какой табличке его искать. Таким образом получается что в credentials я должен записать тип, что потом найти профиль. Но идея состояла в том, что б в Credentials не менять.

что такое профиль и почему у тебя роли и профили это одно и то же?

у кнп можно бесплатно без видосов юзать текст

у кнп можно бесплатно без видосов юзать текст

Понял, спасибо!

или документацию юзать)))

Получается, мне нужно какой-то идентификатор что б знать где стянуть профиль. Вопрос простой, есть три типа пользователей, профиль каждого типа в отдельной Entity. После логина мне надо вывести профиль юзера какой залогинился. Вот и у меня вопрос в том ,как узнать в какой табличке его искать. Таким образом получается что в credentials я должен записать тип, что потом найти профиль. Но идея состояла в том, что б в Credentials не менять.

когда ты логинишься - ты ведь знаешь, в какой "тип" ты логинишься

или документацию юзать)))

без-воз-мезд-но

knplabs/knp-gaufrette-bundle мнения можно? )

knplabs/knp-gaufrette-bundle мнения можно? )

flysystem пободрее был

что такое профиль и почему у тебя роли и профили это одно и то же?

Ну роль я туда прилел что б знать откуда тащить данные. Профиль, это доп инфа о юзере, а так как для каждого типа юзера нужна разная инфа, я думаю что ее надо разделить на несколько Entity. Например у менеджера, номер комнаты где он сидит, у админа номер телефона, а у кастомера адрес. И таким образом, мне после логина надо получить всю инфу по пользователю. В зависимости от типа. Я думал тут роль взять, как идентификатор, с какого репозитория инфу эту тянуть.

или документацию юзать)))

Ну по сути да. Все есть в доке.

1 же, инкапсуляция и все такое. Разделение внутри.

так. Мы видимо ушли в сторону. Идёт разговор о том, как сделать аналог джоина без джоина. Пока без выборки доп. таблицы (в результат), а только для фильтрации. Есть "основная" таблица, и "доп.". Тебе нужно выбрать данные из основной, используя фильтрацию из второй. Storage/Repository "доп." будет давать тебе согласно интерфейсу метод "find*Ids". В "основном" ты будешь его использовать. Я говорю о том, что "find*Ids" будет зачастую дубликатом по функционалу "find*", выдающий столько же строк, но с урезанным кол-вом полей

flysystem пободрее был

спасиб

Ну роль я туда прилел что б знать откуда тащить данные. Профиль, это доп инфа о юзере, а так как для каждого типа юзера нужна разная инфа, я думаю что ее надо разделить на несколько Entity. Например у менеджера, номер комнаты где он сидит, у админа номер телефона, а у кастомера адрес. И таким образом, мне после логина надо получить всю инфу по пользователю. В зависимости от типа. Я думал тут роль взять, как идентификатор, с какого репозитория инфу эту тянуть.

ты же знаешь под кем ты логинишься а стало быть знаешь откуда тянешь инфу)

ты же знаешь под кем ты логинишься а стало быть знаешь откуда тянешь инфу)

Нет, не знаю .. один энтрипоинт )

Нет, не знаю .. один энтрипоинт )

у тебя у пользователя может быть только одна роль?

ты же знаешь под кем ты логинишься а стало быть знаешь откуда тянешь инфу)

Вот задача какраз узнать, по Credentials кто это