Как отладить длину 2019.01.01T01: 01: 01.3213141 или ошибку несоответствия

Question

В одном из наших скриптов выдается ошибка:

'2019.01.01T01:01:01.3213141 length 
'2019.01.01T01:04:34.3213141 mismatch

Скрипт достаточно большой, и все наши функции имеют правильную отладку. Я предполагаю, что это происходит из основной функции KDB. одна из встроенных функций.

Могу ли я внести какие-либо изменения в kdb, чтобы показать мне, какая функция была выполнена, или показать некоторые дополнительные сведения о том, откуда возникла эта ошибка?

ОБНОВЛЕНИЕ: Ошибки не связаны

Answer 1

Как сказал Каллум, страница отладки весьма полезна для этого.

Это похоже на основную ошибку тикерплана. Я бы сосредоточил ваше внимание на любых вставках, вставках или соединениях, которые вы используете в своем коде.

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

Вы знакомы с apply ? Эта функция может пригодиться здесь.

Answer 2

Вы случайно не используете daemonize (или какой-либо другой инструмент для создания фона), чтобы запустить процесс kdb и перенаправить stderr? Если это так, то я полагаю, что именно это вызывает временную отметку при ведении журнала (vanilla KDB регистрирует только ошибку, а не временную отметку, как упомянуто Каллумом). Например,

/start background process
./daemonize -e ~/myerr.log -o ~/myout.log -p ~/mypid.log $QHOME/l64/q -p 5555

/send this process a bad message to create error
q)h:hopen`::5555
q)neg[h]"1+`a"

/check log
>tail -f myerr.log
'2019.11.07T04:47:51.610 type

Конечно, это не решит вашу фактическую ошибку, просто, возможно, объясняет путаницу вокруг отметки времени.

К вашим фактическим ошибкам - как уже упоминалось в других ответах, они, вероятно, вызваны плохо сформированными вставками данных, поступающими в ваш процесс: length означает, что количество полей не равно количеству столбцов, mismatchЭто означает, что соединение может быть неудачным из-за разных типов данных или столбцов.

Чтобы зафиксировать ошибки, у вас есть несколько вариантов:

1. Предполагая, что входящие данные достигли функции upd (upsert / insert) в вашем процессе, измените эту updфункция, чтобы сделать защищенный Eval для захвата сбоев. Что-то вроде

upd:{.[insert;(x;y);{`.err.x set x;`.err.y set y;'z}[x;y]]};

Это будет хранить глобальные переменные .err.x и .err.y. Делайте , а не , делайте это на заводском тикер-заводе - воспроизводите данные в тестовой среде.

Вы можете пойти на общий подход и захватить все входящие записи .z.pg / .z.ps

.z.pg:{@[value;x;{`.err.pg set x;'y}[x]]};
.z.ps:{@[value;x;{`.err.ps set x;'y}[x]]};

Снова сделать не сделать это в производствесистема, она должна использоваться только для тестирования / отладки

Answer 3

Эта сигнализация не является стилем по умолчанию для kdb, указывая на то, что ошибки генерируются нестандартным образом в вашем скрипте. Ошибка уже фиксируется каким-либо образом, когда генерируется сигнал.

Я хотел бы изучить использование функции перехвата ошибок, вы просматривали документацию по отладке ?