Pull to refresh

Comments 9

Спасибо за интересную статью!

/// запротоколировать переданные аргументы и прочитать свойство через прокси ссылку
Method %DispatchGetProperty(Property As %String)
{
#dim Value as %String = $property(..OpenedObject, Property)
do ..LogArgs(Property, Value)
return Value
}

/// запротоколировать переданные аргументы и записать свойство через прокси ссылку
/// log arguments and then dispatch dynamically property access to the proxy object
Method %DispatchSetProperty(Property, Value As %String)
{
do ..LogArgs(Property, Value)
set $property(..OpenedObject, Property) = Value
}


Наверное есть смысл указать разные префиксы для логгирования записи и чтения свойства.
Не знаю как для удаленного доступа, это все таки редкий кейс, а вот я для себя увидел неплохую альтернативу для включения логирования работы с инстансом через LoggingProxy. Не замеряли насколько такая штука «просаживает» производительность?

Хорошее замечание -да, для того, чтобы геттер отличить от сеттера в логе, имеет смысл протоколировать их по разному. Например так:


Method %DispatchGetProperty(Property As %String)
{
#dim Value as %String = $property(..OpenedObject, Property)
do ..LogArgs("Get "_Property, Value)
return Value
}

Method %DispatchSetProperty(Property, Value As %String)
{
do ..LogArgs("Set "_Property, Value)
set $property(..OpenedObject, Property) = Value
}
Не знаю как для удаленного доступа, это все таки редкий кейс, а вот я для себя увидел неплохую альтернативу для включения логирования работы с инстансом через LoggingProxy. Не замеряли насколько такая штука «просаживает» производительность?

Не замерял. В CPU-intensive алгоритма, такое опосредованное использование свойств будет видно. Вопрос в том, что, кроме собственно вызова свойства или метода, исполняется в данном коде. Если "полезный эффект" (например работа с глобалами) составляет существенную часть времени, но и 2ой уровень вызова будет не очень заметен. Собственно, проброс переменного количества аргументов Logs… достаточно оптимизирован. Также как и $property и $method и $classmethod.

Ну и это «логирование» закрывает только объектный доступ, правильно?

А как сделать логирование SQL-доступа к таргет-классу аналогичным образом? И возможно ли?

Хороший вопрос — я еще не экспериментировал с тем, насколько динамическая диспетчеризация свойств будет прозрачно экспортироваться в SQL (и будет ли вообще, без экспорта метаданных в SQL компилятор). Надо поиграться.


Но есть подозрение, что ничего не получится.


@eduard93, adaptun, DAiMor, что думаете?

Вроде как это только для объектного доступа, для SQL ничего не появится
что имена идентификаторов в ObjectScript могут состоять не только из латинских букв и цифр, но и любых «символов алфавита»
более того в том числе и пробелы и часть знаков препинания.

Хмм. Имеешь ли ты в виду случай с закавыченными именами? (О котором я сказал) Или именно без кавычек с пробелами и знаками препинания?

видимо невнимательно прочитал, да с кавычками.
Sign up to leave a comment.