• Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе

    «Анализ защищенности веб-приложений»

    🔥 Записаться бесплатно!

  • CTF с учебными материалами Codeby Games

    Обучение кибербезопасности в игровой форме. Более 200 заданий по Active Directory, OSINT, PWN, Веб, Стеганографии, Реверс-инжинирингу, Форензике и Криптографии. Школа CTF с бесплатными курсами по всем категориям.

глючат профильные документы...

  • Автор темы D!m@n
  • Дата начала
Статус
Закрыто для дальнейших ответов.
D

D!m@n

Добрый день, уважаемые участники!

Создал в базе 1 профильный документ ("общий", без ключа).
В нем одно поле.
Предполагается, что поле будут редактировать:
а) юзеры;
б) шедульный агент.

Предположим, что в поле значение по дефолту "0", а шедульный агент у меня такой:
Код:
Set profiledoc = thisdb.GetProfileDocument( "MainProfile" )
Print profiledoc.GetItemValue( "Status" )(0)
Call profiledoc.ReplaceItemValue( "Status", "1")
Call profiledoc.Save(1, 0, 0)
Print profiledoc.GetItemValue( "Status" )(0)
Тогда агент на сервере выводит:
Код:
0
1
После чего я открываю профиль кнопкой @Command([EditProfileDocument]; "MainProfile") и вижу, что в поле Status стоит значение "0".
Меняю его на -1, сохраняю, открываю - вижу: -1.
Агент на сервере через несколько минут выводит:
Код:
1
1
Захожу в профиль - вижу: -1.
Запускаю этого же агента локально. Он выводит:
Код:
-1
1

NotesPeek'ом смотрел: в базе ОДИН профильный документ.
Есть и другие интересные эффекты.
Например, после отработки серверного агента в документе пропадает поле Form (имя профиля при этом не меняется).
Если сохранить док руками - оно, естественно, заново появляется.

Еще прикол:
Удаляю профильный документ с помощью скриптового агента, запущенного с клиента.
Смотрю NotesPeek'ом - профильных доков в базе НЕТ.
Через несколько минут отрабатывает шедульный агент:
Код:
1
1
Откуда он взял эту единицу?! :))

Понимаю, что можно сделать обычный док и вьюху, в которую он один будет отбираться...
Но уж очень хочется понять, почему такая ерунда происходит...

Буду благодарен за любые комментарии!
 
K

K-Fire

Лотус профайлы как-то кеширует неприлично. Думаю проблема в этом.

Можно заменить профайлы на обычные документы, и если надо иметь высокую производительность доступа, то можно UNID документа подставить "левый", например 32 девятки. Тогда GetDocumentByUNID() использовать можно без любых других операций.
 
Y

yerke

Еще прикол:
Удаляю профильный документ с помощью скриптового агента, запущенного с клиента.
Смотрю NotesPeek'ом - профильных доков в базе НЕТ.
Через несколько минут отрабатывает шедульный агент:
1
1
Откуда он взял эту единицу?!
Set profiledoc = thisdb.GetProfileDocument( "MainProfile" )
достает профил док
а если нет то его создает
 
D

D!m@n

Set profiledoc = thisdb.GetProfileDocument( "MainProfile" )
достает профил док
а если нет то его создает
Это так :) Только обратите внимание на 1-ю единицу :) Если бы он в бэк-энде создал новый, там было бы пусто, а не "1"...

Лотус профайлы как-то кеширует неприлично. Думаю проблема в этом.
Спасибо за ответ!

Неужели все-таки кеширует? Это же ужасно... Хотя это объяснило бы большинство из наблюдаемых мной глюков :)

Можно заменить профайлы на обычные документы, и если надо иметь высокую производительность доступа, то можно UNID документа подставить "левый", например 32 девятки. Тогда GetDocumentByUNID() использовать можно без любых других операций.
Производительность в моем приложении не настолько критична, чтобы искусственно менять униды... Можно и из специальной вьюхи первый док взять.
 
Y

yerke

по идеи так должно быть:

Set profiledoc = thisdb.GetProfileDocument( "MainProfile" ) '=достает или создаст
Print profiledoc.GetItemValue( "Status" )(0) '=печатает то что есть? но откуда здесь 1-ца? если док удален :)
Call profiledoc.ReplaceItemValue( "Status", "1")
Call profiledoc.Save(1, 0, 0)
Print profiledoc.GetItemValue( "Status" )(0) '=печатает 1
 
D

D!m@n

Print profiledoc.GetItemValue( "Status" )(0) '=печатает то что есть? но откуда здесь 1-ца? если док удален
Ну вот в том-то и вопрос. Откуда он эту единицу взял, если док был удален?
Вполне возможно, что он создаст его в строке
Set profiledoc = thisdb.GetProfileDocument( "MainProfile" )
Но тогда откуда в поле "Status" возьмется единица? Этого поля в документе вообще не должно быть, если это только что созданный документ.
 
A

Akupaka

так откуда единица взялась-то, я не понял? :)


зы: извините за флуд, профайлы кешируются как дикие, лучше создать один вид для разнообразных настроек, профайлов и т.п. и доставать их по ключу, красиво и быстро :)
первый док из вида не вариант - для каждого профайла свой вид? О_о
 
D

D!m@n

зы: извините за флуд, профайлы кешируются как дикие, лучше создать один вид для разнообразных настроек, профайлов и т.п. и доставать их по ключу, красиво и быстро
Тоже хороший подход! Правда первый док из вьюхи берется быстрее, чем док по ключу...
ИМХО тут уже больше вопрос предпочтений... Я вот, например, не люблю, чтобы в "сервисные" вьюхи отбирались разнородные документы, если в том нет крайней необходимости...
 
A

Akupaka

Правда первый док из вьюхи берется быстрее, чем док по ключу...
как по мне, так самая длительная операция тут будет - получение вида :)
а про док по ключу - отключайте перед работой с видом автоапдейт, будет быстрее :)

link removed
 
30.05.2006
1 345
12
BIT
0
Неужели все-таки кеширует? Это же ужасно... Хотя это объяснило бы большинство из наблюдаемых мной глюков :)
Ну, ё-моё... Аматоры-граблеходцы

И в док-ции написано, и на всех форумАХ исталдычено: профайлы кешируются в памяти, так-же как и эл-ты дизайна. Это их основное свойство, для того и придуманы.

И не надо микроскопом забивать гвозди :)
 
D

D!m@n

И в док-ции написано
Не поверил, полез проверять :)
И все-таки нашел... В стандартной документации разработчика упоминание о кешировании профильных доков действительно встречается, но всего в одном месте, причем весьма неожиданном - в разделе "XML for Domino".
Вот все, что там есть:
Profile documents are different from standard documents because they are invisible in views, they are not included in the document count for a database, and they are cached while the database containing them is open. This makes profile documents useful for storing database-wide data, such as environment variable information, or per-user data, such as user preference information. In either case, because profile documents are cached, you can quickly retrieve information stored in them.
 
Статус
Закрыто для дальнейших ответов.
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!