подключаешь Httpkernel и делаешь дела

отдельная точка входа

и постепенно переносишь код, и через контейнер делаешь "мосты" к старому приложению

почему надо отказаться от API - его надо написать) И проще его не писать)

ну или сделать просто фасады над старой системой

почему надо отказаться от API - его надо написать) И проще его не писать)

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

иметь 2 приложения с мостами такая себе затея. еще и api между ними вводить

@sergey_smile чего вы вообще ожидаете от перехода на другой фреймворк?

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

даже лютый гавнокод на кохане можно сделать нормальным

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

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

ну или сделать просто фасады над старой системой

мне нравится эта идея)

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

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

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

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

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

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

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

I am busy now, chat to you later

?‍♂️

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

Ok

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

т.к. в последнее время все чаще нависает недоверее к функционалу - это еще хуже

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

шаблон проектирования - фасад

да-да, я же написал что нравится мне эта идея)

у кого-то есть успешный опыт миграции с id на uuid?

особенно кейсы с foreign keys и вот это вот все?

uuid это ms sql?

uuid это глобальный идентификатор

сталкивался с uniqueid от ms sql.

это то же самое https://ru.wikipedia.org/wiki/UUID

>Here is a PR that shows the differences between 3.2 and 3.3 for the Symfony Demo app: https://github.com/symfony/symfony-demo/pull/483/files?diff=split

все в кучке

https://github.com/kamranahmedse/design-patterns-for-humans держите вот кстати, описано для людей)

зашел на сайт чувака, верхний пост в блоге - "Do not use auto increments!"

вот все говорят юзать UUID, а как его юзать вместо айдишника, если никто не знает как существующие данные смигрировать?:)

в монге неавтоинкременты юзаем))

а uuid рисково немного(читай непривычно)

меня просто уже воротит, когда нужно делать что-то типа $this->entityManager->flush($command->invoice); $this->scheduler->schedule(CreateInvoice::COMMAND_NAME, [$command->invoice->getId()]);

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

ну а как ты будешь это решать через ууид?

ну а как ты будешь это решать через ууид?

иметь только один флаш

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

ну или столько флашей, сколько бизнес-транзакций

но не костыли такого вида :(

ну а как ты будешь это решать через ууид?

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

меня просто уже воротит, когда нужно делать что-то типа $this->entityManager->flush($command->invoice); $this->scheduler->schedule(CreateInvoice::COMMAND_NAME, [$command->invoice->getId()]);

ну такая себе затея шедулить несуществующую запись

как на счет вынести это из цикла?

ну скажем сразу сохранить пачку, а потом по списку отправить

ну такая себе затея шедулить несуществующую запись

ну в данном случае шедулер в бд пишет, это в рамках одной транзакции

наверное не самый удачный пример

а вообще даже если бы он не писал в ту же базу, а в какую-то очередь то try/catch на флаше и удаление этой записи из очереди? хотя есть конечно риск, что пока идут коммиты\роллбеки, сообщение уже уйдет

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

да блин, проблема не в шедулере же

а в том что сущность неконсистентна до флаша

а в том что сущность неконсистентна до флаша

http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/working-with-associations.html#transitive-persistence тебе сюда

http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/working-with-associations.html#transitive-persistence тебе сюда

я почитал, но не совсем понял как это относится к этой проблеме. https://ocramius.github.io/doctrine-best-practices/#/62 - пункт предпоследний, я про него говорил

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

+1

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

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

переходи на СУБД где есть секвенсы и не парься

забудь про mysql

и не будет проблем с автоинкрементами)

например постгрятина

ERROR: S client not available

и будут у тебя айдишки по персисту а не по флашу

а от автоикрементов в базе логика не должна уж точно зависеть

инкремент сделали а транзакцию откатили - уже дырки)

ну все равно, значит на до флаша, а до персиста будет неконстистентно

ну все равно, значит на до флаша, а до персиста будет неконстистентно

тогда юзай uuid

смысл uuid же в том, чтобы прям после создания объекта все поля были на месте

ну я о том и говорю

смысл uuid же в том, чтобы прям после создания объекта все поля были на месте

ну так сделай ее айдихой сущности а для урлов например юзай автоинкременты или компактные версии uuid

что пока uuid не заменит id полностью (автоинкремент или секвенс - не важно), то смысла нет

https://github.com/pascaldevink/shortuuid

может кому пригодится

Пиветта вроде советует https://packagist.org/packages/ramsey/uuid

ну как бы да

https://github.com/pascaldevink/shortuuid

Годно, спс

та штука что я скинул лишь кодирует/декодирует uuid в более короткую форму, для урлов например

прикоснусь к умному в пятницу. Всем здрасте.

Сегодня среда вроде как

Сегодня среда вроде как

Завтра выходной

завтра отдыхаем. сегодня пятницп

Так что пятница

офисники подтянулись)

Гребцы

так в офисе ж лучше))

Кому?

мне

пообщаться можно))

Работать надо, а не общаться

в офисе стабильность. обучение. кормят. поиграть можна. пообщаться.

стабильность?)

т.е. на удаленке ее нет