сча затестим

не затестим(

повис терминал

да, работает

<?php function test(iterable $a) { return array_map('intval', array_merge(...$a)); } function gen(): iterable { yield [1,2]; yield [3,4]; } var_dump(test(gen()));

хм.. какая версия пыхи?

7.1

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

Интерфейс драйвера? Это который из DBAL? И почему это он не должен быть завязан на БД?

Ой, что-то я некропостнул, однако.

Кто-нибудь знает как Easy Admin отстроить от Doctrine? Мне нужно отображать в админке сущности на основании только json файлов и иерархии папок. Sonata, по видимому, позволяет это сделать более интуитивно, чем Easy Admin

он завязан на метаданных доктрины, увы.

Ну, там, вероятно, как и в Sonata, можно отцепить Datagrid и с его помощью сделать. Правда, тогда проще взять только Datagrid и не брать всё остальное - то есть, речи об EasyAdmin уже не будет идти.

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

у них в вики типа есть эта задача в беклоге, но не Iterable, а ArrayObject... правда хз насколько рабочий беклог у них

@Enleur, в описании чата: Официальный slack: https://symfony.com/slack-invite По ссылке: This invite link is no longer active.

Кстати, отправил в github.com/mr-mig/ru-tech-chats пуллреквест на добавление этого чатика: https://github.com/mr-mig/ru-tech-chats/pull/125 Странно, что его там до сих пор нет.

Кстати, отправил в github.com/mr-mig/ru-tech-chats пуллреквест на добавление этого чатика: https://github.com/mr-mig/ru-tech-chats/pull/125 Странно, что его там до сих пор нет.

может не надо?)

может не надо?)

Нет, ну если хотите, конечно, могу отозвать PR. Я, в принципе, понимаю, что в притоке населения свои минусы, но чатик достаточно интересный.

> Достаточно крупный фактурный

> Достаточно крупный фактурный

Могу ведь и так написать :)

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

Интерфейс драйвера? Это который из DBAL? И почему это он не должен быть завязан на БД?

Так другого интерфейса нет. Забыл упомянуть. Имел в виду именно это. Все дальше уже строится на этом интерфейсе без вариантов. Но я доктрину то понимаю - добавлять дополнительные слои абстракции для таких редких случаев как работа не с СУБД - сомнительно при ограниченных разработческих ресурсах

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

сделай по ДДД

типа CustomJsonRepository

и вытаскивай в нем из файлов в методах find, findAll и т.п.

Да. Мысль была в эту сторону посмотреть. Но это для меня еще не исследованная технология и я смоневался. Так что спасибо! Ты мне добавил уверенности

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

Надо исследовать, попрактиковать

там у тебя не будет em... будет типа $product = $productRepository->find($id);

можно еще интерфейс завести

вернее будет $productJsonRepository

а в нем ты открываешь файлы, парсишь жсон и т.д. все это веселье )

нафига оно тебе не понятно )

Нет ты не понял. Я про ассоциации говорю: $productJsonRepository->find($id)->getSubProduct();

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

ну ты можешь на них забить.. $category = $categoryJsonRepository->find($product->getCategoryId())

))

да. Согласен. Интересно, как глубоко меня заведет эта кроличья нора под именем "забей" ))

Но DDD же. Так что все нормально

?

ну если тебе сильно надо то ты можешь и релейшены запилить

ну если тебе сильно надо то ты можешь и релейшены запилить

Может быть. Я, просто, не знаю каким геммороем это может обернуться. Сейчас я переключился на другой проект. Вернусь к этому через два дня

@Enleur, в описании чата: Официальный slack: https://symfony.com/slack-invite По ссылке: This invite link is no longer active.

спасибо исправлю

@Enleur, в описании чата: Официальный slack: https://symfony.com/slack-invite По ссылке: This invite link is no longer active.

На офф сайте такая же ссылка и там также

Ребзи

Репозиторий имеет право возвращать скаляр?

Типа кол-во "таких-то" записей?

И т.п.

я так понимаю репы должны только энтити возвращать

Репозиторий имеет право возвращать скаляр?

вообще не должен

А куда тогда положить такие агрегатные запросы? ... Тоже интересно)

делаешь новый Finder интерфейс и туда пихаешь все это дело

но в реалиях симфони я честно даже не знаю чтобы кто-то так делал

обычно все что только можно пихают в репосы

у нас в коде репос это DAO с другой вывеской...

Ну вот у нас тоже, угу

еще можно с readmodel и cqrs упороться, но это уже немного другое

а если создать класс например GetCountActiveUsers туда передать em интерфейс или конекшн и в нем один метод execute в кором dql и возвращает int?

users это я от балды

это еще окрамиус на докладе предлагал

а в наш класс юзкейса мы уже передаем этот GetCountActiveUsers

я смотрел какой-то его доклад.. видимо им и навеяло

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

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

Я свои коллекции делал для связей. Удобно для добавления объектов только определенного типа (с помощью тайпхинта). Делал интерфейс UsersCollection, например. Потом создавал класс ArrayUsersCollection, делал extend от ArrayCollection, реализовывал свой интерфейс. Таким образом, ты не даешь внешнему коду использовать функции ArrayCollection от доктрины, а только свои, которые определенны в интерфейсе. Ну как-то так.

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

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

Я свои коллекции делал для связей. Удобно для добавления объектов только определенного типа (с помощью тайпхинта). Делал интерфейс UsersCollection, например. Потом создавал класс ArrayUsersCollection, делал extend от ArrayCollection, реализовывал свой интерфейс. Таким образом, ты не даешь внешнему коду использовать функции ArrayCollection от доктрины, а только свои, которые определенны в интерфейсе. Ну как-то так.

ага, тоже в эту сторону смотрю, спасибо)

обычно все что только можно пихают в репосы

Это хорошо еще если в репозитории ). "Умные" люди, с которыми я сталкиваюсь, в контроллерах всю модель реализуют. Я сюда к вам попал и душа радуется - видеть как эстеты перебирают тру реализации

ERROR: S client not available

если запросы строятся и делаются не в репосах, то это можно попрощаться с юнит тестами

если запросы строятся и делаются не в репосах, то это можно попрощаться с юнит тестами

Ха! Я на это слышал, что модульные тесты круче. Мол зачем мокать объект тестирования )). Еще один ответ на это: "Мы используем BDD и не паримся"

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

Интеграционные, опечатался

и в итоге не проекте нет ни интеграционных, ни юнит тестов

если запросы строятся и делаются не в репосах, то это можно попрощаться с юнит тестами

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

Ха! Я на это слышал, что модульные тесты круче. Мол зачем мокать объект тестирования )). Еще один ответ на это: "Мы используем BDD и не паримся"

интеграционные тесты это обман

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

я про createQuery в контроллерах, сервисах и тд вперемешку с другой логикой

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

Могли бы чуть более подробнее про вынесение выборок в отдельные объекты, пожалуйста, т.к. не совсем вас понял)

я про createQuery в контроллерах, сервисах и тд вперемешку с другой логикой

https://cs5.pikabu.ru/images/big_size_comm/2014-06_5/14034523941357.jpg

Могли бы чуть более подробнее про вынесение выборок в отдельные объекты, пожалуйста, т.к. не совсем вас понял)

выше примерчик был

а если создать класс например GetCountActiveUsers туда передать em интерфейс или конекшн и в нем один метод execute в кором dql и возвращает int?

только не execute, а __invoke

выше примерчик был

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

а если создать класс например GetCountActiveUsers туда передать em интерфейс или конекшн и в нем один метод execute в кором dql и возвращает int?

можно query builder передавать, или обертку которая только создает запрос. EM передавать опасно

слиииишком жирный интерфейс, слишком высокая связанность

можно query builder передавать, или обертку которая только создает запрос. EM передавать опасно

чем опасно?

с жирным интерфейсом пока ничего не слелаешь, там всегда будут persist/remove/flush методы

только не execute, а __invoke

Вы класс-выборку инжектите в какой-либо сервис, верно? и потом вызываете его внутри сервиса?

Вы класс-выборку инжектите в какой-либо сервис, верно? и потом вызываете его внутри сервиса?

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

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

А куда вы складываете классы-выборки? Папочка Queries?

можно QueryFunction назвать в принципе

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

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

Скалярные запросы - это как?:)

getTotalUsers()

или еще хуже getTagsUsageCount()

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

Я так понимаю, это неплохо, если таких запросов мало. Но если репос твой начинает расти, может быть трабл с одними гэтЭто, гэтТо, гэтЕщеЧто

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

Фаулер пишет, что репозиторий выступает как in-memory реализация обьектов. Поэтому скалярных запросов там не должно быть в принципе, каждый метод должен возвращать обьект. А запросы ты там делаешь или стучишься по сети или сохраняешь все в память, это детали реализации

https://martinfowler.com/eaaCatalog/repository.html

если гэтЭто всегда возвращает сущность этого репоса, то эт окей

ну если делать метода типа function getUserCommentCount(User $user);

Аааа, затупил блин, сори