Александр Воробьев, ну я не встречал такой проблемы, хотя я делал diff на огромном проекте. Правда я везде использую исключительно PostgreSQL. Конечно я сомневаюсь, что дело именно в СУБД :). Я бы покопал в сторону аннотаций\атрибутов сущностей, возможно там косяк и доктрина тупит, когда сравнивает их. Например вы в аннотациях\атрибутах указываете только обязательные параметры, и доктрина при diff из-за того, что нет статических имён, пытается заново сгенерировать имена индексам и т.д.
На счёт того, что вам отмечать как решение. Уже не важно, я удаляю свои ответы через 2 недели, если их не отметили. :), поэтому благодаря вам и другим, кто не отмечает, новый людям заново придётся задавать вопрос. К сожаленью такая систему у этого сайта, которая поощряет только отмеченные ответы.
я бы ответил, но мне лень лезть в свой код, чтобы показать вам решение. Ведь вы никогда не отмечаете ответы как правильные, поэтому читайте документацию сами там всё есть, конечно не явно и нужно подумать.
In_hape, он вероятно имеет ввиду, что токены должны быть скрыты под капотом, тобишь в бэкенде и не видны клиенту. Вы отправляете запрос в бэкенд, он там нужными токенами обращается к банку, получает ответ от банка, и потом отдаёт нужную информацию клиенту.
Быстрее будет в PostgreSQL, ОЧЕНЬ БЫСТРО (нано секунды, потому что там есть индексы). А в MySQL сделайте тесты и сравните с php, но в сравнение с PostgreSQL, будет медленнее в тысячи раз, а если точнее в 25000x раз.
Вы пытаетесь микроскопом забивать гвозди.
Нужно не откатывать транзакции только потому что, она всегда падает, а сделать так, чтобы её не нужно было откатывать вообще.
Найдите почему происходит откат и справьте это.
HellWalk, при чём тут именно файликовые логи? Я вообще говорю, работать через очередь, раз у вас там тысячи воркеров. А если отвалится, то восстановите и продолжите вытаскивать старую очередь.
UUID:D а ещё лучшеulid.