metaclass: (Default)
metaclass ([personal profile] metaclass) wrote2009-04-26 11:28 am

Строго типизированный лог

А вот интересно, возможна ли такая концепция: писать не текстовый лог, а строго типизированный, чтобы в будущем можно было грузить сохраненные в него объекты и выполнять над ними какие-нибудь запросы?
Сейчас анализ логов сводится к 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] metaclass.livejournal.com 2009-04-26 05:12 pm (UTC)(link)
Я пишу и читаю руками, но это не логи, а короткие файлы конфигов.

[identity profile] metaclass.livejournal.com 2009-04-26 05:13 pm (UTC)(link)
А он кстати поделен, на схему или dtd и собственно данные :)
Без этого запросы к нему особо не поделаешь. И если сериализовать объекты - в качестве словаря выступает структура класса.

[identity profile] madeveloper.livejournal.com 2009-04-26 05:15 pm (UTC)(link)
А что если "бросать" в качестве эксепшенов сами объекты или в объекте-эксепшене ссылку на них? И в обработчике раскладывать их по полям таблиц (на основе метаданных языка, хотя не со всеми прокатит)? Конечно матаданные в БД разрастутся, зато все под рукой...

[identity profile] madeveloper.livejournal.com 2009-04-26 05:19 pm (UTC)(link)
Кстати, пишу сейчас "тул" для генерации языковых классов на базе метаданных исходной БД и хранением там же. Что бы к объектам обращаться не через SQL или даже LINQ, а банальным вызовом конструкторов и доступом к типизированным атрибутам и методам, включая форейн-референсы. Готово для Delphi, сейчас начинаю делать для C#. Конечно пока не все реализовано, но все зависит от спроса. Есть интерес?

[identity profile] madeveloper.livejournal.com 2009-04-26 05:27 pm (UTC)(link)
Вы можете предложить что-то лучше?

[identity profile] madeveloper.livejournal.com 2009-04-26 05:29 pm (UTC)(link)
Не, ну метаданные описания это несколько иное. Я имел ввиду избыточность самого набора данных, а именно именований аттрибутов и служебные "обрамления".

[identity profile] metaclass.livejournal.com 2009-04-26 06:20 pm (UTC)(link)
Это ж ORM классический, типа NHibernate. Уже неоднократно обсуждали, пришли к выводу, что не для всех случаев пригодно.

Например, если через такой API делать редактирование базы для юзеров - придется еще и прикручивать генератор GUI из метаданных класса, если делать запросы - опять же придется LINQ или что-то похожее вызывать. У NHibernate для таких целей есть собственный язык запросов (кривоватый), из которого SQL генерируется.

В общем, вещь наиболее подходящая, если нужно бизнес-логику сложную считать, используя объекты, чтобы для каждого объекта загрузчик руками не писать. Или если изначально есть цель напрямую с базой не работать, а изолироваться от нее и работать с объектами. [livejournal.com profile] arbinada про кошмары такого подхода неоднократно писал.

А беда вся от того, что у разных СУБД даже SQL разный, не говоря уже о его процедурных расширениях, где кто во что горазд пляшет.

[identity profile] migmit.vox.com (from livejournal.com) 2009-04-26 06:30 pm (UTC)(link)
Да. В зависимости от конкретной цели.

[identity profile] theiced.livejournal.com 2009-04-26 06:30 pm (UTC)(link)
Ясно оракель головного моска приправленный буйной хымыыльманеей.

[identity profile] madeveloper.livejournal.com 2009-04-26 06:32 pm (UTC)(link)
Не, ну это уже в практику вошло. Только что-нибудь дельное придумаешь, оказывается это придумали задолго до тебя. С другой стороны, существующие решения не подходят по многим причинам (контроль на стадии начала выполнения, языковая распространенность).

Генератор GUI прикручивать не обязательно, я реализую DataSource автоматически (для Delphi). Более того, уже автоматически реализуются и GUI, но не в виде отдельных класов, а в виде единственного класса формы для редактирования моих объектов.

[identity profile] madeveloper.livejournal.com 2009-04-26 06:36 pm (UTC)(link)
Цель простая - представление инстансов объектов в текстовом (human-readable) виде. С возможностью универсального доступа к его пропертям по имени.

[identity profile] madeveloper.livejournal.com 2009-04-26 06:41 pm (UTC)(link)
Самое смешное, что XML я не использую принципиально, а Оракл лишь там, где это диктует заказчик. Что касется данного случая, то журналы я веду в БД, но на стадии проектирования продумываю структуры и способы журналирования.

[identity profile] migmit.vox.com (from livejournal.com) 2009-04-26 06:49 pm (UTC)(link)
Тогда XML отпадает сразу. Ибо не human-readable.

[identity profile] metaclass.livejournal.com 2009-04-26 06:50 pm (UTC)(link)
Я такое тоже делал (автоматическая генерация GUI), но в итоге всегда упираюсь в то, что реализация некоторых вещей оказывается сложнее, чем их руками нарисовать в дизайнере.

[identity profile] madeveloper.livejournal.com 2009-04-26 06:59 pm (UTC)(link)
Здрасьте, приехали... И чем он хуже C++, HTML, C#? Я бы сказал что он в сто раз более human-readable...

[identity profile] madeveloper.livejournal.com 2009-04-26 07:06 pm (UTC)(link)
У меня тоже GUI не было самоцелью, но 30% USER GUI оно, как ни странно, закрыло. Самоцелью был контроль соответствия структур, когда проверка идет на стадии компиляции и выполнения, а также способ доступа из языка без использования конструкций типа ('DEPT_ID').AsInteger, а нормального обращения к типизированным свойствам, включая ссылочные. А вопрос сложнее/проще решается по месту, одно другого у меня не исключает. Хотя после написания такого framework'а я стал больше обращать внимания на бизнес-логику на стороне сервера БД, когда процедуры компиляться в свойства объектов, или реализуют наборы данных (вместе со view), которые я раньше вытаскивал SQL запросами.

[identity profile] permea-kra.livejournal.com 2009-04-26 07:08 pm (UTC)(link)
Щаззз. Вполне работается.

[identity profile] permea-kra.livejournal.com 2009-04-26 07:10 pm (UTC)(link)
>>И вместо того что бы тупо пойчитать лог придётся писать прогу которая из хымыыля сделает что нибудь читаемое.
Какую прогу писать???
Есть xmllint, чтобы отформатировать в читабельный вид.
Есть xqilla для тестов и обработки.

[identity profile] migmit.vox.com (from livejournal.com) 2009-04-26 07:15 pm (UTC)(link)
HTML - был human-readable в эпоху HTML 1.0 и академического дизайна. Чтобы убедиться, что он таковым более не является, достаточно взглянуть на код этой страницы.

C++ - если писать очень аккуратно и исключительно руками, то он будет струдомчитабельным. Если генерировать из какой-то другой программы (например, из компилятора высокоуровневого языка), то нечитабельность практически гарантирована. Причём, проблемы что у XML, что у HTML, что у C++ схожие (хотя и не идентичные) - безумная избыточность синтаксиса в первую очередь.

C# я знаю очень плохо и ничего на нём не писал, хелловорлды не в счёт. Так что, говорить о нём не буду.

[identity profile] madeveloper.livejournal.com 2009-04-26 07:53 pm (UTC)(link)
Так эта избыточность как раз и связана с human-readability. Чтобы C++ генерировали откуда-то и при этом сложно читаемый - первый раз слышу. HTML даже этой страницы нормально читается. Другое дело что 130К неформатированного кода на ЛЮБОМ языке будут неразберабельны. Точнее сложно понимаемы, но все-таки ЧИТАЕМЫ.

PS. А что, какие-то логи более читабельны чем XML? Там ты даже названия и назначение полей не всегда увидишь...

[identity profile] theiced.livejournal.com 2009-04-26 08:03 pm (UTC)(link)
Вообще - для читаемых данных с плавающим форматом есть ямл.

[identity profile] migmit.vox.com (from livejournal.com) 2009-04-26 08:16 pm (UTC)(link)
> Так эта избыточность как раз и связана с human-readability.

Фигня полная. Лаконичный Haskell на несколько порядков читабельнее безумно избыточных плюсов.

> HTML даже этой страницы нормально читается.

То-то специальных программ для его чтения понаписали немеряно.

> Другое дело что 130К неформатированного кода на ЛЮБОМ языке будут неразберабельны.

130K иксэмэля легко превратятся в 60K чего-нибудь типа ямла, а в обычных логах легко уместятся в 30K.

> Чтобы C++ генерировали откуда-то и при этом сложно читаемый - первый раз слышу.

Ну, генераторов нечитабельного C просто пруд пруди. С плюсами сложнее - их мало кто вообще генерит, за ненадобностью.

> Там ты даже названия и назначение полей не всегда увидишь...

И это, зачастую, хорошо. Потому что "117:24" - гораздо более читабельно, чам "row='117' column='24'", я уж молчу про ситуации, когда полей десять штук и из-за прихоти иксэмэль-генератора row оказывается на одном конце, а column - на другом.

[identity profile] madeveloper.livejournal.com 2009-04-26 08:31 pm (UTC)(link)
Ну он имхо еще менее понятен чем xml. А главное менее распространен. Just Yet Another....

[identity profile] madeveloper.livejournal.com 2009-04-26 08:49 pm (UTC)(link)
Позвольте, вы утверждали что XML вообще не читаем. Более компактные языки не всегда являются более читаемыми, так как предполагают более глубокие знания самого языка. Конструкции типа return (func(x) ? 0 : GetLastResult()) я не считаю более читабельными чем процедурное выражение. При этом объем лога ничего не говорит о его читаемости. Выразительность языка и его "бинарность" - это разные вещи. Может попросить вас код этой страницы выразить на Haskell? Вы уже начинаете путать процедурные, функциональные и языки разметки в одну кучу. Десять штук полей - это фигня ;) Зато при незначительном изменении структуры, все продолжит работать, без необходимости что-то переделывать. Ну и опять же упомянутый XQuery - стандарт де-факто для интеграции.

[identity profile] theiced.livejournal.com 2009-04-26 11:26 pm (UTC)(link)
За бизнес логику на стороне БД сразу отрывать яйца и садить в бочку с жабами.

Page 2 of 4