И ключ на 19-21
Забыл ещё штуку которой фиксится половина всего - скотч
Юра
The Ant
Забыл ещё штуку которой фиксится половина всего - скотч
Ахах, да! В фильме марсианин за счёт этой имбовой штуки выживал 🤣
Михаил
Вы ещё про мусорный контейнер забыли. Фиксит 100% сломанного
Иван
Вы ещё про мусорный контейнер забыли. Фиксит 100% сломанного
надо ещё карточку с деньгами, которая вместо 100% сломанного позволяет новое купить
Михаил
надо ещё карточку с деньгами, которая вместо 100% сломанного позволяет новое купить
Ну или спартанские условия жизни.
Михаил
Не всмысле с мужчинами спать, а про минимализм
Konstantin
Господа, проблема, помогите, если кто сталкивался
Есть три entity, но мне нужно чтоб они смотрели на одну таблицу
User\Entity\User
Admin\Entity\User
Post\Entity\User
У меня есть аттрибут ORM\Table(name = 'users')
При создании миграции мне пишет The table with name "users" already exists.
Никто не подскажет, как сконфишить доктрину?
Ivan
extends BaseUser?))
Konstantin
Пробовал
Konstantin
При наследовании он вообще не видит аттрибуты которые у меня в BaseUser, и пытается создать таблицу user, где тоже сыпиться с ошибкой
Сергей
Оно?
https://www.doctrine-project.org/projects/doctrine-orm/en/2.17/reference/inheritance-mapping.html#class-table-inheritance
Konstantin
В таком кейсе он будет создавать для каждой сущности свою таблицу, то есть, ничего не поменяется, в примере там
class Employee extends Person - создаст employee
Konstantin
Проверил еще раз, ругается на дубликаты
Konstantin
Что то мне кажется, это невозможно(
Иван
Оно?
https://www.doctrine-project.org/projects/doctrine-orm/en/2.17/reference/inheritance-mapping.html#class-table-inheritance
вроде оно, дискриминировать надо
Nikolay
Что то мне кажется, это невозможно(
Либо через простое наследование в коде, либо через single table inheritance
Юра
Это скорее что-то больше похоже на вьюхи
Юра
Но вроде доктрина так не умеет
Konstantin
Konstantin
Иван
роли не назначаются?
Konstantin
Да я просто тут DDD изучаю, пытаюсь дробить все на контексты
И получается, что меня юзер одновременно существует в трех контекстах
Да, дискридитация не помогает, она дробит прям в бд пользователей по типу, и использует потом флаг для выборки при каком то запросе
Konstantin
Видимо придется сделать Shared)
Сергей
Лучше юзеров и админов разделить полностью. И не юзать в этом случае никаких дискриминаторов.
В подавляющем большинстве случаев у админов и пользователей не будет ничего общего
Иван
Лучше юзеров и админов разделить полностью. И не юзать в этом случае никаких дискриминаторов.
В подавляющем большинстве случаев у админов и пользователей не будет ничего общего
ну да
а если есть корпоративные аккаунты и в рамках них персональные - это тоже две разные сущности
Иван
дискриминатор - это когда сущности в одном списке потом
Сергей
Тем более речь про ограниченные контексты.
А тут мухи с котлетами плотно сцеплены получаются
Юра
Да я просто тут DDD изучаю, пытаюсь дробить все на контексты
И получается, что меня юзер одновременно существует в трех контекстах
Да, дискридитация не помогает, она дробит прям в бд пользователей по типу, и использует потом флаг для выборки при каком то запросе
Тут смотря как делать. Если ты сделаешь отдельные энтити от энтити доктрин, и репозитории отдельные от доктрин, то ты сможешь сделать как ты хочешь
Юра
Т.е. если не будешь напрямую использовать орм слой, создавай хоть десять разных юзеров в каждом контексте
Юра
А вообще возможно это у тебя проблема одной большой модели
Юра
Сделай юзер как грубо говоря айди модель, с минимумом полей, а остальные через OneToOne и сможешь в каждом контексте создавать дополнительные энтити типо UserInfo, UserContacts, UserRegistration, UserDevice и т.д.
Павел
Да я просто тут DDD изучаю, пытаюсь дробить все на контексты
И получается, что меня юзер одновременно существует в трех контекстах
Да, дискридитация не помогает, она дробит прям в бд пользователей по типу, и использует потом флаг для выборки при каком то запросе
В контекстах по хорошему и разные таблицы. Возможно это и не юзеры или не нужны вовсе там.
Иван
Да я просто тут DDD изучаю, пытаюсь дробить все на контексты
И получается, что меня юзер одновременно существует в трех контекстах
Да, дискридитация не помогает, она дробит прям в бд пользователей по типу, и использует потом флаг для выборки при каком то запросе
чувак
ДДД идёт от потребности бизнеса, а не от книжки по ДДД
Михаил
чувак
ДДД идёт от потребности бизнеса, а не от книжки по ДДД
Вы не правы. Благодаря книжкам про ddd прогеры стали дорого стоить
Михаил
Я думаю что проблема решается чисто интерфейсами.
Каждый контекст декларирует свой энтити интерфейс и репозитори интерфейс. А уже классы User и UserRepository имплементируют эти интерфейсы и всё работает нормально.
Михаил
Можно ещё вообще не завязываться на доктрину, забыл как паттерн называется, ща гляну.
Короче у тебя есть юзкейс. Внутри него идёт цикл
1) получить/создать сущность
2) вызвать доменные методы
Как понять что поменялось в сущности без UnitOfWork? А просто когда вызываешь доменные методы внутри сущности создавай доменный ивент. Когда подходишь к концу юзкейса - запроси все доменные ивенты у сущностей и уже на их основе производи сохранения
Михаил
Но это овер. Как по мне doctrine лучший способ. Просто работай не с конкретной реализацией, а с интерфейсами
Иван
Можно ещё вообще не завязываться на доктрину, забыл как паттерн называется, ща гляну.
Короче у тебя есть юзкейс. Внутри него идёт цикл
1) получить/создать сущность
2) вызвать доменные методы
Как понять что поменялось в сущности без UnitOfWork? А просто когда вызываешь доменные методы внутри сущности создавай доменный ивент. Когда подходишь к концу юзкейса - запроси все доменные ивенты у сущностей и уже на их основе производи сохранения
так юзкейс на то и юзкейс, что ты точно знаешь, что тут меняется
Михаил
так юзкейс на то и юзкейс, что ты точно знаешь, что тут меняется
Никак нет. Я точно знаю кто участники и какие действия совершаются.
Про то что что-то меняться будет - мне до лапочки.
Юзкейс как накормить Ивана Лещёва:
1) Взять Ивана Лещёва
2) Спросить у Ивана его предпочтения
3) На основе предпочтений запросить приготовить еду.
4) Попросить Ивана съесть эту еду.
То КАК будет готовиться еда, и куда она там проваливается внутри Ивана - юзкейсу абсолютно всё равно
Михаил
Можно ещё вообще не завязываться на доктрину, забыл как паттерн называется, ща гляну.
Короче у тебя есть юзкейс. Внутри него идёт цикл
1) получить/создать сущность
2) вызвать доменные методы
Как понять что поменялось в сущности без UnitOfWork? А просто когда вызываешь доменные методы внутри сущности создавай доменный ивент. Когда подходишь к концу юзкейса - запроси все доменные ивенты у сущностей и уже на их основе производи сохранения
А, прошу прощения. Пункт 3 не часть юзкейса. Это можно сделать уже на слоях выше. Удалил
The Ant
Ваша проблема в том, что вы пытаетесь решить проблему, которую создает автоматическая миграция 😄
Из-за нее начинаете выдумывать всякое.
Vite4eg
Всем привет. Чем вы ротируете логи? Монологом или линуксовыми утилитами?
The Ant
Всем привет. Чем вы ротируете логи? Монологом или линуксовыми утилитами?
Еластиком. Но надо бы на какой Локи переехать...
Vite4eg
А почему эластик нет? Слишком замудрёный?
The Ant
Жрет памяти много
The Ant
Всем привет. Чем вы ротируете логи? Монологом или линуксовыми утилитами?
Elastic curator, он довольно гибко настраивается. Можно по времени логи удалять.
kakoi-to-noob
https://github.com/doctrine/orm/releases/tag/3.0.0
Михаил
Михаил
Кто-то уже пробовал обновиться? BCH очень много, страшно
kakoi-to-noob
Кто-то уже пробовал обновиться? BCH очень много, страшно
если до этого деприкейты фиксились, должно без проблем завестись
Михаил
если до этого деприкейты фиксились, должно без проблем завестись
Нуууу, если я заглушил деприкейшоны, это считается фиксом?
kakoi-to-noob
Нуууу, если я заглушил деприкейшоны, это считается фиксом?
это не точно! Аннотации точно выпиливать придется, если используются
Kirill
там вроде yaml конфиги выпилили, так что пока жду пакет чтоб их вернуть
Kirill
там офигенная аргументация была, кстати, типа "yaml не валидируется") А то что json схема и валидирует и автокомплитит, и подсказывает json, json5, neon, yaml, php и кучу других форматов — "это другое"
Михаил
На самом деле не понимаю зачем симфе (почему так исторически сложилось) 3 формата конфигурирования.
Ямал, xml, php. Почему просто на php не остановились. Да, он не такой декларативный. Зато не надо было всякие when@dev, языки выражений изобретать, fqcn (особенно когда константу пытаешься получить)
Ну и то что это не код, надо отдельное расширение ставить чтоб переходить к месту декларирования, или из кода понять что этот класс используется чисто в конфиге и не надо помечать его как неиспользуемый.
А ну и «я понял что накосячил в конфиге только во время компиляции» Не для этого я из c++ уходил.
Юра
PHP не очень удобно анализировать всякими тулзами, например той же ide
Юра
Неудобно модифицировать
Null
Ямал в целом огонь.
Тот же flex модифицирует их инкрементно
Михаил
Ч.Т.О.?
PhpStorm не удобно анализировать php?
И при чём тут анализ и модификация? 99% времени Я анализирую и модифицирую конфиг. И во время этого 1%, когда я обновляю пакет, можно просто кинуть эксепшон что что-то неправильно настроено, я сам поправлю
Александр
На самом деле не понимаю зачем симфе (почему так исторически сложилось) 3 формата конфигурирования.
Ямал, xml, php. Почему просто на php не остановились. Да, он не такой декларативный. Зато не надо было всякие when@dev, языки выражений изобретать, fqcn (особенно когда константу пытаешься получить)
Ну и то что это не код, надо отдельное расширение ставить чтоб переходить к месту декларирования, или из кода понять что этот класс используется чисто в конфиге и не надо помечать его как неиспользуемый.
А ну и «я понял что накосячил в конфиге только во время компиляции» Не для этого я из c++ уходил.
Вроде на github было написано, что будет полный переход на php конфиги.... Только не понятно когда. Хотя может уже передумали.
Vlad
Михаил
Очень врядли они сделают полный переход. Очень много легоси.
Vlad
В целом никто не мешает юзать пых конфиги сейчас)
Юра
Интересно насколько пых конфиги ускоряют. У нас огромный проект там куча бандлов, долго кеш конечно чистится
Юра
Если бы был пхп коныиг ускорило бы или нет
Vlad
Так конфиги тоже билдится))
Александр
Вряд ли парсинг yaml сильно грузит....
Vlad
Если говорим про dsl, а не массивчики
Vlad
Интересно насколько пых конфиги ускоряют. У нас огромный проект там куча бандлов, долго кеш конечно чистится
Autowire можно выключить где не нужен
The Ant
Интересно насколько пых конфиги ускоряют. У нас огромный проект там куча бандлов, долго кеш конечно чистится
rm -rf ./var/cache отменили?
The Ant
Там в сообщении про чистится
Михаил
Ну блин, ты же понял
Михаил
bin/console ca:cl
Михаил
эта команда включает в себя момент вармапа
Михаил
что перекомпилирует кеши. И это самый долгий момент.