![[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
no subject
no subject
no subject
Я нечто похожее сейчас проектирую/делаю, но клиент немного более интеллектуальный, и таки, скорее всего, придется логику из БД убирать - хочу сделать поддержку разнообразных баз.
Но тем не менее, логика в виде сложных запросов-отчетов в виде SQL останется в базе - если это писать на каком-нибудь c# (LINQ у меня нет - влом к 3.5 фреймворку привязываться и деплоить его) или дельфи - кода будет как бы не больше, чем SQL-запросов во всех возможных диалектах :)
no subject
no subject