![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Строго типизированный лог
А вот интересно, возможна ли такая концепция: писать не текстовый лог, а строго типизированный, чтобы в будущем можно было грузить сохраненные в него объекты и выполнять над ними какие-нибудь запросы?
Сейчас анализ логов сводится к grep, awk и прочей тексто-ориентированной линуксятине. Существует мнение, что это (текстово-ориентированный обмен данными между линуксовыми утилитами через |) хорошо, но у меня это усиленно ассоциируется с электронным прибором, у которого все платы соединены одинаковыми никак не различимыми разъемами, а плата сама решает, "что делать с входным сигналом", т.е. нет никакой защиты от обобщенного индуса-дяди-Васи-телемастера-из-соседнего-гаража.
Плохо то, что большинство интересующих объектов обычно содержат кучу пропертей-ссылок на всякие дебри, которые вне рабочего контекста смысла не имеют, а чтобы их исключить, нужно какой-то флаг на проперть типа атрибута/аннотации "NotLoggable". А это плохо тем, что логгинг не должен требовать лишнего от объектов, с которыми он работает.
Сейчас вывод в лог выглядит следующим образом:
А желательно было бы так:
А DebugAll был бы хитрым метапрограммным макросом, который бы доставал, в зависимости от флагов, имя метода, this, все локальные переменные и параметрами с именами и значениями, сериализовал бы это дело во что-то машинно-читабельное и писал бы в лог.
Сейчас анализ логов сводится к grep, awk и прочей тексто-ориентированной линуксятине. Существует мнение, что это (текстово-ориентированный обмен данными между линуксовыми утилитами через |) хорошо, но у меня это усиленно ассоциируется с электронным прибором, у которого все платы соединены одинаковыми никак не различимыми разъемами, а плата сама решает, "что делать с входным сигналом", т.е. нет никакой защиты от обобщенного индуса-дяди-Васи-телемастера-из-соседнего-гаража.
Плохо то, что большинство интересующих объектов обычно содержат кучу пропертей-ссылок на всякие дебри, которые вне рабочего контекста смысла не имеют, а чтобы их исключить, нужно какой-то флаг на проперть типа атрибута/аннотации "NotLoggable". А это плохо тем, что логгинг не должен требовать лишнего от объектов, с которыми он работает.
Сейчас вывод в лог выглядит следующим образом:
mLog.DebugFormat("OnAuthenticateRequest: {0} {1} {2}",
httpApplication.Request.RawUrl,
httpApplication.Request.UserAgent,
httpApplication.Request.UserHostAddress);
А желательно было бы так:
mLog.Debug("some_user_comment",LogFlags.LocalVars | LogFlags.MethodName | LogFlags.This | LogFlags.Parameters);
А DebugAll был бы хитрым метапрограммным макросом, который бы доставал, в зависимости от флагов, имя метода, this, все локальные переменные и параметрами с именами и значениями, сериализовал бы это дело во что-то машинно-читабельное и писал бы в лог.
no subject
Опять же - меганабор из grepов, sedов и прочих awkов становится непременим. Как жить дальше?
no subject
no subject
no subject
no subject
no subject
no subject
Конечно, с ними xml не распарсишь, но достать его из базы для обработки каким-нибудь консольным xquery процессором - запросто.
Но я бы предпочел не xml, а автоматически сгенеренную при компиляции строго типизированную схему для логов, тогда чистым SQL можно будет анализировать все что в голову придет.
no subject
no subject
no subject
Например, если через такой API делать редактирование базы для юзеров - придется еще и прикручивать генератор GUI из метаданных класса, если делать запросы - опять же придется LINQ или что-то похожее вызывать. У NHibernate для таких целей есть собственный язык запросов (кривоватый), из которого SQL генерируется.
В общем, вещь наиболее подходящая, если нужно бизнес-логику сложную считать, используя объекты, чтобы для каждого объекта загрузчик руками не писать. Или если изначально есть цель напрямую с базой не работать, а изолироваться от нее и работать с объектами.
А беда вся от того, что у разных СУБД даже SQL разный, не говоря уже о его процедурных расширениях, где кто во что горазд пляшет.
no subject
Генератор GUI прикручивать не обязательно, я реализую DataSource автоматически (для Delphi). Более того, уже автоматически реализуются и GUI, но не в виде отдельных класов, а в виде единственного класса формы для редактирования моих объектов.
no subject
no subject
no subject
no subject
(no subject)
no subject
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
no subject
no subject
Какую прогу писать???
Есть xmllint, чтобы отформатировать в читабельный вид.
Есть xqilla для тестов и обработки.
no subject
no subject
Ну, удачи в смотрении глазами 25М лога с мешаниной выводов десятка так подсистем.
no subject
no subject
no subject
no subject