Строго типизированный лог
Apr. 26th, 2009 11:28 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassА вот интересно, возможна ли такая концепция: писать не текстовый лог, а строго типизированный, чтобы в будущем можно было грузить сохраненные в него объекты и выполнять над ними какие-нибудь запросы?
Сейчас анализ логов сводится к 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, все локальные переменные и параметрами с именами и значениями, сериализовал бы это дело во что-то машинно-читабельное и писал бы в лог.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2009-04-26 05:11 pm (UTC)Конечно, с ними xml не распарсишь, но достать его из базы для обработки каким-нибудь консольным xquery процессором - запросто.
Но я бы предпочел не xml, а автоматически сгенеренную при компиляции строго типизированную схему для логов, тогда чистым SQL можно будет анализировать все что в голову придет.
no subject
Date: 2009-04-26 05:15 pm (UTC)no subject
Date: 2009-04-26 05:19 pm (UTC)no subject
Date: 2009-04-26 06:20 pm (UTC)Например, если через такой API делать редактирование базы для юзеров - придется еще и прикручивать генератор GUI из метаданных класса, если делать запросы - опять же придется LINQ или что-то похожее вызывать. У NHibernate для таких целей есть собственный язык запросов (кривоватый), из которого SQL генерируется.
В общем, вещь наиболее подходящая, если нужно бизнес-логику сложную считать, используя объекты, чтобы для каждого объекта загрузчик руками не писать. Или если изначально есть цель напрямую с базой не работать, а изолироваться от нее и работать с объектами.
А беда вся от того, что у разных СУБД даже SQL разный, не говоря уже о его процедурных расширениях, где кто во что горазд пляшет.
no subject
Date: 2009-04-26 06:32 pm (UTC)Генератор GUI прикручивать не обязательно, я реализую DataSource автоматически (для Delphi). Более того, уже автоматически реализуются и GUI, но не в виде отдельных класов, а в виде единственного класса формы для редактирования моих объектов.
no subject
Date: 2009-04-26 06:50 pm (UTC)no subject
Date: 2009-04-26 07:06 pm (UTC)no subject
Date: 2009-04-26 11:26 pm (UTC)no subject
Date: 2009-04-27 12:27 am (UTC)no subject
Date: 2009-04-27 01:40 pm (UTC)no subject
Date: 2009-04-27 05:22 am (UTC)no subject
Date: 2009-04-27 01:40 pm (UTC)no subject
Date: 2009-04-27 05:22 pm (UTC)no subject
Date: 2009-04-27 06:26 pm (UTC)Я нечто похожее сейчас проектирую/делаю, но клиент немного более интеллектуальный, и таки, скорее всего, придется логику из БД убирать - хочу сделать поддержку разнообразных баз.
Но тем не менее, логика в виде сложных запросов-отчетов в виде SQL останется в базе - если это писать на каком-нибудь c# (LINQ у меня нет - влом к 3.5 фреймворку привязываться и деплоить его) или дельфи - кода будет как бы не больше, чем SQL-запросов во всех возможных диалектах :)
no subject
Date: 2009-04-27 07:16 pm (UTC)no subject
Date: 2009-04-27 08:53 pm (UTC)no subject
Date: 2009-04-27 02:24 pm (UTC)Оба мнения обоснованные, сознательно и аргументированно выбрать между ними при реализации системы с нуля невозможно без предварительных данных.
Я бы предпочел третий вариант - писать структуры данных и логику единую для всех баз, а затем компилировать их в конкретный диалект SQL и структуры данных конкретной СУБД, но это безумие и оверкилл для 99% моих проектов, т.к. сложность реализации такой вещи перекрывает все сложности с ручной реализацией достаточного для работы функционала на одной или даже нескольких реально нужных СУБД.
no subject
Date: 2009-04-27 03:25 pm (UTC)no subject
Date: 2009-04-27 04:41 pm (UTC)no subject
Date: 2009-04-27 08:51 pm (UTC)