Comments 22
Заказчику повезло с Team Lead-ом.
Им найден способ как практически бескровно начать «апгрейдить» текущее ИТ-решение.
Правда, этот подвиг скорей всего останется не замеченным Заказчиком, но я вот для себя добавил Александра в «избранных» хабрачан, если мне или кому-то из моих друзей понадобится Мастер.
Тоже написал статью про наш «legacy» проект на днях.
Так как был руководителем проектов, то начали раскручивать клубок через технические задания. Приводя в порядок их и те куски, что им соответствовали внутри.
В нашем случае Проблема выглядела так, когда мы делали что-то одно, у нас отваливалось в нескольких других местах. У Заказчика сложилось впечатление что «Нормально» сделать с первого раза мы ничего не можем. Причина её заключалась «в сплошном коде», в котором было непонятно где заканчивается одна фича и начинается новая, и задача была разметить его на «функциональные области».
UPD. «Сплошной код» это была не вина Разработчиков, так как система изначально была коробочной и для настройки, а не для того чтобы на её основе разрабатывать отраслевое ИТ-решение.
Прошу простить мой технический русский, не разработчик, это мой обывательский взгляд РП-БА на ИТ-систему.
представьте 100K строк кода в старой версии контур-экстрена на сишарп с первым билдом в 1998
Не могу себе представить C# в 1998 году. Посмотрел историю вопроса на википедии: Проект C# был начат в декабре 1998 и получил кодовое название COOL (C-style Object Oriented Language). Версия 1.0 была анонсирована вместе с платформой .NET в июне 2000 года, тогда же появилась и первая общедоступная бета-версия; C# 1.0 окончательно вышел вместе с Microsoft Visual Studio .NET в феврале 2002 года.
С order проблема тоже решается просто:
/**
* @ORM\Column(name="`order`", type="integer")
*/
private $order;
Просто обрамляем апострофами
Enum тяжелый вопрос, для себя мы решили, что лучше работать без них. Но это выбор каждого, здесь я не буду призывать вас их выкидывать.
Про заказы, да, ваш способ работает, если вам нужен номер заказа, а нам нужен объект заказа, и вот такой способ не работает:
/**
* @ORM\ManyToOne(targetEntity="Orders")
* @ORM\JoinColumn(name="`order`", referencedColumnName="id")
*/
private $order;
/**
* @ORM\Entity()
* @ORM\Table(name="`order`")
*/
Возможно, Ваша проблема решилась апострофами в имени таблицы, если дело не в поле
Вот этот вариант сработал, только проблема, что данные в базу попадают, а когда выбираешь, поле order = null. Надо смотреть, что происходит в гидраторе. А у вас какая версия симфонии и доктрины (orm и dbal)?
Вообщем дебаг показал, что на 2.4.8 (это наша текущая версия), такой вариант не подходит, дело в этой строчке: https://github.com/doctrine/doctrine2/blob/v2.4.8/lib/Doctrine/ORM/UnitOfWork.php#L2624
Он показывает такие значения и не грузит объект
$data[$srcColumn] = null
$srcColumn = "order"
$data['order'] = null
$data['`order`'] = 3442 * @ORM\Table(name="`order`")
и убрать их в
* @ORM\JoinColumn(name="order", referencedColumnName="id")
На офф сайте доктрины можно узнать, что по умолчанию экранирование полей используемых для джоинов игнорируется. Поэтому у вас поле `order` интерпритируется неверно (с апострофами). Прежде чем написать, я проверил это локально.
Да, так проблем почти нету, объекты попадают в базу, вытягиваются оттуда, но к сожалению связь не удаляется.
$entity->setOrder(null);Приводит к ошибке: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'order = NULL WHERE id = 41771' at line 1
Было бы интересно узнать, если кто-то разрулил и такой кейс более изящно
Я обновил блок про решение проблемы, мы через пару дней нашли способ оставив связь обойти эту ошибку. Мы погрузились в недры доктрины, и реализовали новый хак, который работает на более глубоком уровне и чуть более изящный, чем первый вариант на уровне объекта. Спасибо за ваши комментарии, они нам реально помогли.
Это не много. Это вполне себе такая средняя (толстая) entity в какой-нибудь ММО. Типа игрока или торговца.
А в банковском деле это даже не java-транзакция.
Всё зависит от того, что это за 2000+ строк.
Если это нормально побитый на методы класс + куча каких-нибудь геттеров/сеттеров, то и ладно (хоть и многовато на мой вкус, но читабельно).
Но реальность такова, что чаще всего в легаси-проектах в этих 2000+ строках полтора метода, которые занимаются всем и дёргают всё возможное (и SQL через heredoc, и строковые подстановки вместо шаблонов, и глобальные переменные/синглтоны/реестры, и т.д). Такое разбирать и поддерживать действительно сложно.
Новая жизнь legacy проекта