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

Создал в базе 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

Откуда он взял эту единицу?! )

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

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

 

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

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

 

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

Set profiledoc = thisdb.GetProfileDocument( "MainProfile" )
достает профил док
а если нет то его создает

 

Set profiledoc = thisdb.GetProfileDocument( "MainProfile" )
достает профил док
а если нет то его создает

Это так Только обратите внимание на 1-ю единицу Если бы он в бэк-энде создал новый, там было бы пусто, а не "1"...

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

Спасибо за ответ!

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

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

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

 

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

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

 

Print profiledoc.GetItemValue( "Status" )(0) '=печатает то что есть? но откуда здесь 1-ца? если док удален

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

 

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


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

 

зы: извините за флуд, профайлы кешируются как дикие, лучше создать один вид для разнообразных настроек, профайлов и т.п. и доставать их по ключу, красиво и быстро

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

 

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

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

link removed

 

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

Ну, ё-моё... Аматоры-граблеходцы

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

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

 

И в док-ции написано

Не поверил, полез проверять
И все-таки нашел... В стандартной документации разработчика упоминание о кешировании профильных доков действительно встречается, но всего в одном месте, причем весьма неожиданном - в разделе "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.

 

D!m@n
Неправда.
Прямо в разделе "Profile forms" написано.

Profile documents allow for quick data retrieval, because they are cached while the database that stores them is open.

 

Прямо в разделе "Profile forms" написано.

Во-во
Правда никто там подробно не разжевал, во что-же это кеширование выливается.
Ну, так Help - скорее справочник, чем учебник

 

D!m@n
Неправда.
Прямо в разделе "Profile forms" написано.

Точно. Слона-то я и не приметил...