![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Пока разбирался с ситуацией обнаружил баг.
Помимо трансферного робота сделал альтернативную схему то ли бекапленья, то ли клонирования. Простенько и надёжно: при формировании ответа на наряд робот генерит файлик с копией записи. Файлик потом отправляем к новой базе где его можно загрузить.
До пересылки дело не дошло. Но сделал и забыл. :)
А когда стал разбираться с предыдущей проблемой обнаружил этот кусок алгоритма и удивился. Заглядываю в файл и в некоторых местах обнаруживаю, что один из параметров у меня потерян.
Озадачился.
Долго искал и не мог понять где засада. А отлаживать и так жутко неудобно. Там код такой и условия его работы своеобразные. Через отладку прогоняю — всё есть. В рабочем режиме вдруг замечаю, что параметр пропадает не всегда. Что за чёрт?
Наконец обнаруживаю.
Назначение параметров у меня происходит не только в основной фазе выполнения нарядов, но и в фазе получения, если наряд был прислан повторно и его не нужно выполнять, а можно выслать хранящуюся в БД информацию. И вот баг был именно в коде этой редко выполняемой части. Более того, до тех пор пока я не решил записи бекапить (где понадобились почти все параметры) это баг сидел и ни на что не влиял.
А поскольку хоббийная деформация, то сразу всплыла ассоциация, что этот код с багом сидел там как «мусорные гены». На самом деле ведь дофига кода в софте может быть в таком спящем режиме. Особенно всякие либы. Тем более в разных ООПах.
Помимо трансферного робота сделал альтернативную схему то ли бекапленья, то ли клонирования. Простенько и надёжно: при формировании ответа на наряд робот генерит файлик с копией записи. Файлик потом отправляем к новой базе где его можно загрузить.
До пересылки дело не дошло. Но сделал и забыл. :)
А когда стал разбираться с предыдущей проблемой обнаружил этот кусок алгоритма и удивился. Заглядываю в файл и в некоторых местах обнаруживаю, что один из параметров у меня потерян.
Озадачился.
Долго искал и не мог понять где засада. А отлаживать и так жутко неудобно. Там код такой и условия его работы своеобразные. Через отладку прогоняю — всё есть. В рабочем режиме вдруг замечаю, что параметр пропадает не всегда. Что за чёрт?
Наконец обнаруживаю.
Назначение параметров у меня происходит не только в основной фазе выполнения нарядов, но и в фазе получения, если наряд был прислан повторно и его не нужно выполнять, а можно выслать хранящуюся в БД информацию. И вот баг был именно в коде этой редко выполняемой части. Более того, до тех пор пока я не решил записи бекапить (где понадобились почти все параметры) это баг сидел и ни на что не влиял.
А поскольку хоббийная деформация, то сразу всплыла ассоциация, что этот код с багом сидел там как «мусорные гены». На самом деле ведь дофига кода в софте может быть в таком спящем режиме. Особенно всякие либы. Тем более в разных ООПах.