наконец то избавимся от /** * @var Photo */

А такое и правда бесит)

наконец то избавимся от /** * @var Photo */

в одну же строчку можно

и глаза не вываливаются

Приветствую из Одессы мамы! Предлагаю сделать встречу в Одессе в ноябре, познакомиться, пообщаться. Кто не в Одессе на день приехать можно. Интересно? Пишите в личку, если соберется хотя бы 5 человек, уже будет о чем поговорить.

кто-то хорошо в написании расширения варит?

в частности про ресурсы вопрос

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

Может имена норм делать и не надо будет описание?)

п.с. но на самом деле dbal - вполне сносный вариант

а сколько в команде человек? насколько разнороден их уровень?

а сколько в команде человек? насколько разнороден их уровень?

к чему вопрос? использование доктрины никак не зависит от размера команды. Ровно как и использование дбал. Ну а чем меньше уровень, тем больший мрак с доктриной творят. Что в общем-то ещё 1 повод хорошенько задуматься, стоит ли.

Но мне тоже интересно к чему был вопрос

к чему вопрос? использование доктрины никак не зависит от размера команды. Ровно как и использование дбал. Ну а чем меньше уровень, тем больший мрак с доктриной творят. Что в общем-то ещё 1 повод хорошенько задуматься, стоит ли.

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

Может имена норм делать и не надо будет описание?)

Предпочитаю и имена, и комменты, пусть иногда они могут быть излишне

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

да где там конкретный вопрос-то?

я до сих пор не могу понять суть этого конкретного вопроса

дбал используется тогда, когда нет нужды в использовании uow, а обмазываться голым pdo лениво. Просто, как сахар. размер команды? похеру. навыки? похеру

да где там конкретный вопрос-то?

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

очень большая потеря. Мог бы просто спросить, который час, раз решил доколупаться :)

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

еще раз - нет никакой корреляции между размером команды и "юзать dbal вместо orm"

это просто разные инструменты

да и сами подходы могут сильно различаться

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

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

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

ну так какой вопрос такой и ответ

а ты всегда только orm юзаешь? и для репортов? или иногда тоже используешь dbal?

еще раз - нет никакой корреляции между размером команды и "юзать dbal вместо orm"

использование orm не запрещает использовать dbal если это требуется. мне интересен опыт человека который использовал только dbal/pdo в последние пару лет в команде разработчиков

использование orm не запрещает использовать dbal если это требуется. мне интересен опыт человека который использовал только dbal/pdo в последние пару лет в команде разработчиков

у него там вообще event sourcing потому в целом применение ORM не особо нужно

еще пример когда ORM не нужен - когда у тебя нет связанных реляций. То есть все данные для операции хранятся в рамках одной таблицы (при помощи jsonb). Один агрегат - одна таблица

я не использовал ни dbal, ни pdo, использовал pg там, где не впихивался es. тем не менее, вариант с pg от варианта с тем же pdo не отличается ни чем. Размер команды, где я использовал нативные средства (читай, без доктрины) от 4х до 20 человек. Их навыки? от джуниоров, до синьоров.

но опять-таки, я связи не вижу...

в моей текущей картине почти весь контроль за жизненным циклом передан сагам. Поэтому всякие тонкие модели - в порядке вещей. Это не сущности в привычном понимании, просто access object, если можно так выразиться. И ORM в такой картине мира не впихивается аще никуда, ибо по сути роль uow выполняется средствами саг

если брать пример попроще, то самый распространённый - круд. Лень то и дело толкает взять сущность, впихнуть сериалайзер и пойти пить смузи. Если ты делаешь апи, то с вероятностью в 100500% orm тебе не нужна.

и пофиг сколько людей будет в команде.

я не использовал ни dbal, ни pdo, использовал pg там, где не впихивался es. тем не менее, вариант с pg от варианта с тем же pdo не отличается ни чем. Размер команды, где я использовал нативные средства (читай, без доктрины) от 4х до 20 человек. Их навыки? от джуниоров, до синьоров.

вполне интересный опыт, а для crud операций появились ли какие либо хелперы при этом? как то решался вопрос стандартизации написания sql кода при этом? бывали ли у джунов проблемы? как вы реализовывали поиск (конкатенация запроса или ...)?

вполне интересный опыт, а для crud операций появились ли какие либо хелперы при этом? как то решался вопрос стандартизации написания sql кода при этом? бывали ли у джунов проблемы? как вы реализовывали поиск (конкатенация запроса или ...)?

те же вопросы но тебе в плане работы с orm)

ммм есть примеры? а то мне это кажется похоже на отчеты какието

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

> конкатенация запроса или ... шутки ради - любой квери билдер это увы и ах лишь конкатенация запросов. Причем иногда выгоднее делать конкатенацию подзапросами (аля SELECT * FROM (SELECT * FROM (SELECT id, name FROM ...) WHERE... ) WHERE ..

вполне интересный опыт, а для crud операций появились ли какие либо хелперы при этом? как то решался вопрос стандартизации написания sql кода при этом? бывали ли у джунов проблемы? как вы реализовывали поиск (конкатенация запроса или ...)?

ну в первое время клешнями sql писали. Потом прикрутил qb простенький. джуны в целом на моём текущем месте работе не вариант, поэтому они в контексте этого кейса не рассматриваются. с dbal джуны ок дружат, им даже проще.

вполне интересный опыт, а для crud операций появились ли какие либо хелперы при этом? как то решался вопрос стандартизации написания sql кода при этом? бывали ли у джунов проблемы? как вы реализовывали поиск (конкатенация запроса или ...)?

что касается стандартизации, то я немного не понял о чём речь. Как написан будет запрос, с использованием TABLE или table? сколько букв в строке, или что?

ну в первое время клешнями sql писали. Потом прикрутил qb простенький. джуны в целом на моём текущем месте работе не вариант, поэтому они в контексте этого кейса не рассматриваются. с dbal джуны ок дружат, им даже проще.

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

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

ну, тут ничё не скажу, ибо...)

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

именованных не бывает. doctrine/dbal например сверху навешивает мегапримитивный парсер запросов который косячит

ну и на счет негативный или позитивный опыт - все эти мелочи причесываются

По-идее такое же решается через кастомизацию QB

именованных не бывает. doctrine/dbal например сверху навешивает мегапримитивный парсер запросов который косячит

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

что касается стандартизации, то я немного не понял о чём речь. Как написан будет запрос, с использованием TABLE или table? сколько букв в строке, или что?

да именно про это, используем ли SQL 92 и не используем VIEWs

По-идее такое же решается через кастомизацию QB

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

да именно про это, используем ли SQL 92 и не используем VIEWs

а почему я могу не хотеть юзать вьюшки?

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

занятно, попробую на днях

да именно про это, используем ли SQL 92 и не используем VIEWs

тут мне наплевать. Корректно работает и славно (под корректностью понимается оптимальность запроса). против вьюшек я ничего не имею

а почему я могу не хотеть юзать вьюшки?

например view с union по нескольким таблицам может быть медленным

например view с union по нескольким таблицам может быть медленным

ну тогда значит это тебе не подходит, но причем тут факт юзать или не юзать

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

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

просто интересно понять - принималось ли такое решение или нет (я sql 92 и views привел для примера), выше уже ответ был

я бы не стал подобных решений принимать.

потому что это тупо

у тебя есть postgresql - все, дальше юзай то что решает поставленную задачу эффективно и что бы поддерживать было удобно

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

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

)))

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

ну типа чаще всего это не оправдано, но да бывают исключения.

событийная модель, все дела) пинок от постгреса, например, бывает полезен :)

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

Я противник какой-либо неявной записи в БД. Т.е. хранимки ок, но только если они делают ряд сложных селектов (можно с использованием временных таблиц), не более.

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

наоборот, орм - серьёзно срёт им в голову и тормозит развитие.

зато сколько видел синьоров, которые, к примеру, шардинг доктриной пилили - не пересчитать. так что тут сколький вопрос, на который однозначного ответа нет. Авось у @fes0r получится закрыть хотя бы часть

Привет. Давно я не писал ничего тут ? Насчёт Doctrine. Не признаю маппинг анотациями. Пишу чистую доменная модель, которая не знает о деталях хранилища абсолютно ничего. В доменной модели есть только интерфейсы репозиториев с ЯВНЫМИ методами для персистенции. На инфраструктурном уровне пишу XML схемы маппинга доменных сущностей + реализовываю интерфейсы репозиториев, которые используют Doctrine.

Насчёт того, что ORM срёт в голову – да, и это касается любой ORM: что Doctrine, что любого AR. Чтобы дошло, предлагаю домен на три сущности и даю задание написать персистенцию руками без какой-либо ORM/DBAL: гидрации руками, запросы руками, чистый PDO. Обычно хорошо помогает понять, чего стоит магия.

я не разделяю фанатизма по выпиливанию аннотаций. В моей картине мира - чушь)

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

Подписываюсь под каждым словом

Привет. Давно я не писал ничего тут ? Насчёт Doctrine. Не признаю маппинг анотациями. Пишу чистую доменная модель, которая не знает о деталях хранилища абсолютно ничего. В доменной модели есть только интерфейсы репозиториев с ЯВНЫМИ методами для персистенции. На инфраструктурном уровне пишу XML схемы маппинга доменных сущностей + реализовываю интерфейсы репозиториев, которые используют Doctrine.

- что такое ЯВНЫЕ методы для персистенции? типа save? или все же add? - интерфейс под репозиторий один или ты его дробишь? - где делаешь flush?

1. Явные – не надеюсь на то, что будет UoW который потом что-то сам посохраняет (или нет). Обычно есть add() который только создаёт новые и persist(), которые апдейтит. 2. Зависит. Если репозиторий простой – один. Если разухабистый – делаю несколько. 3. Хотелось бы после обработки всего HTTP запроса, но иногда делаю и в процессе обработки, если требуется

> persist(), которые апдейтит вне зависимости от того, откуда взял сущность, дергаешь persist?

1. Явные – не надеюсь на то, что будет UoW который потом что-то сам посохраняет (или нет). Обычно есть add() который только создаёт новые и persist(), которые апдейтит. 2. Зависит. Если репозиторий простой – один. Если разухабистый – делаю несколько. 3. Хотелось бы после обработки всего HTTP запроса, но иногда делаю и в процессе обработки, если требуется

1. то есть ты игнорируешь UoW и Identity map, а твой persist делает бесполезный $em->persist($entity) так? То есть у тебя не репозиторий а скорее table gateway. 2. Если ты не дробишь интерфейс - то тогда вопрос, зачем ты вообще его делаешь. Ты планируешь разные реализации репозитория? Или это следствие того что у тебя разделение на слои влияет на структуру модуля? 3. вот эти иногда - оч сомнительные штуки

> persist(), которые апдейтит вне зависимости от того, откуда взял сущность, дергаешь persist?

у меня обычно подобное ассоциируется с "не прочитал доку к доктрине"

у меня обычно подобное ассоциируется с "не прочитал доку к доктрине"

ну я тоже такой был

все такими были

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

все такими были

кстати, а ты как называешь штуки, которые на запись?)

ну, мол, если репозиторий ток на чтение, то как называется херовина на запись?)

Угу, с Doctrine работаю немного, потому могу не осознавать, где ошибаюсь ? Буду рад, если услышу что-то новое для себя! 1. Да 2. Домен используется в разных сервисах приложения, реализация репозитория отличается. В части сервисов нужен ограниченный набор возможностей репозитория, потому разделяю 3. Иногда – например в неудачных местах архитектуры где flush нужен для того, чтобы дёрнуть внешний сервис (считай RPC), которому нужны данные, которые я создал в процессе обработки запроса

persist это не о сохранении, это о том чтобы UoW узнал о твоем обьекте. уже насмотрелись такого $obj = $repo->find(1); $em->persist($obj); $em->flush($obj);

Да, я это понимаю. Но я умышленно не хочу привязываться к UoW, потому в интерфейсе делаю метод persist(), который делает на первый взгляд бесполезный ->persist(), но остаётся в интерфейсе для реализации в сервисах, которые могут не пользоваться (и не пользуются) Doctrine

Так можно сделать сервис в слое приложения отвечающий за транзакции и использующий реализацию доктриновской сессии из слоя инфраструктуры. И забыть о прямых flush`ах

Да, я это понимаю. Но я умышленно не хочу привязываться к UoW, потому в интерфейсе делаю метод persist(), который делает на первый взгляд бесполезный ->persist(), но остаётся в интерфейсе для реализации в сервисах, которые могут не пользоваться (и не пользуются) Doctrine

а доктрина тогда для чего?

Ну типа возьми ZendDb (row\table gateway) и буде щасце)

ну, мол, если репозиторий ток на чтение, то как называется херовина на запись?)

Репозиторий ток на запись

На чтение файндеры

На чтение файндеры

Ясн, пасиб

На чтение файндеры

А что ты называешь файндерами? Я просто привык немного к другой формулировке

На чтение файндеры

файндеры - классы под чтение некоего набора сущностей\конкретной сущности с N методов или query functions?

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

хм, господа, а как в phpDoc'е указать тип данных, которые возвращает генератор?

хм, господа, а как в phpDoc'е указать тип данных, которые возвращает генератор?

\Generator<string>

мерси)

Но шторму всё равно насрать)

бля)))

так нечестно)

а как, чтоб не насрать?