• 🔥 Бесплатный курс от Академии Кодебай: «Анализ защищенности веб-приложений»

    🛡 Научитесь находить и использовать уязвимости веб-приложений.
    🧠 Изучите SQLi, XSS, CSRF, IDOR и другие типовые атаки на практике.
    🧪 Погрузитесь в реальные лаборатории и взломайте свой первый сайт!
    🚀 Подходит новичкам — никаких сложных предварительных знаний не требуется.

    Доступ открыт прямо сейчас Записаться бесплатно

Как лучше сделать в форме историю ответных документов?

  • Автор темы Автор темы masyna
  • Дата начала Дата начала
Мы перед селектом вьюхи делали DEFAULT $Ref:=myParent;
Работало, так как в документах $Ref отсутствовало.
С вариантом Field $REF не экспериментировали
если в доке есть родной $REF, то вариант с myParent не прокатит!
по крайней мере у меня не прокатило
 
oshmianski
Уточняю: Не прокатит вариант из-за DEFAULT!
Парент это или не парент, тут вообще не имеет значения.
DEFAULT работает, только если поля нет и не добавляет поле в документ.
Об отсутствии дочерних я явно упоминала при описании решения.
Если поле есть, думаю, его можно перебить с помощью варианта TIA.
Вопрос только - нужно ли, поле ж тогда сохранится в доке?
Вообще кто-то использовал его вариант, он рабочий?
 
и разрушить иерархию на родных $REF, если уже используется?
я так понял, можно юзать или $REF или свою альтернативную.
одновременно не получится
можно и так и так но по правильному лучше проектировать базу БЕЗ респонсов, тогда можно на базе поставить флажок "не поддерживать иеархию" что существенно скажется на производительности
 
Почему во вьюхе не сохранится?
Akupaka
в этом уверен. действует только в пределах отображения вида.
поверим твоему опыту, это меня сегодня глючит...
А если поизвращаться ;) - так что получится, если мультивалью?
FIELD $Ref := @If(@IsAvailable(MyRef) & @IsAvailable($Ref); MyRef:$Ref; $Ref);
 
мдя? тесты и другие доказательства?
А что админского хелпа вам уже не достаточно?

Disable specialized response hierarchy information
By default every document stores information that associates it with a parent document or a response document. Only the @functions @AllChildren and @AllDescendants, which are often used in view selection and replication formulas, use this stored information. Maintaining this information has a significant, negative effect on database performance.
To improve database performance, disable the response hierarchy information in databases that don't use these @functions by selecting the Advanced database property "Don't support specialized response hierarchy."
Disabling the response hierarchy information has no effect on views and replication formulas that display information hierarchically without using @AllChildren and @AllDescendants.
Disabling the response hierarchy information sets NotesDocument.Responses to 0 documents.
If you select or deselect the "Don't support specialized response hierarchy" property, you must compact the database so that the setting takes effect. Compacting in this case makes a temporary copy of the database, so your system must have the disk space to make the copy.
Tip You can also run the Compact server task with the -h or -H option to enable or disable this property and then compact.
 
TIA
Получится "нет". или не получится. ;)
В общем, что получится или не получится в итоге, я не понял :google:
Лана, пока извраты отставим - примем как аксиому, что мультизначное $Ref будет некорректно обрабатываться в представлении.
*Просто интересно было, как отреагирует на такую конструкцию, что и как отобразится в представлении.*
 
можно и так и так но по правильному лучше проектировать базу БЕЗ респонсов,
;)
Гораздо больше выигрыш в производительности получится, если БД спроектировать так, чтоб документы были общедоступными.
Возьмите это себе за правило и никогда не используйте разграничение доступа к документам.
Ещё возьмите за правило иметь в БД строго одну вьюшку. Надо было бы и от неё отказаться, но Нотес не позволит.
Агенты -- зло ибо грузят сервер. Документ в БД -- строго один, а то в производительности потеряем.


Добавлено:
Получится "нет". или не получится.

Да, получается что "нет". :google: Вобщем, многозначность $REF не приводит к желаемому эффекту -- отображению одного и того же документа респонсом сразу под несколькими документами в одном и том же представлении. Как именно повлияет -- не помню, вобщем ничего полезного.
 
TIA
Вобщем, многозначность $REF не приводит к желаемому эффекту -- отображению одного и того же документа респонсом сразу под несколькими документами в одном и том же представлении. Как именно повлияет -- не помню, вобщем ничего полезного.
ну например подвесит индексер а тот положит сервер ;)
 
TIA
даже пробывал создавать несколько одноименных итемов $REF
за 10 лет с лотусом много чего приходилось пробывать :)
 
Мы в соцсетях:

Взломай свой первый сервер и прокачай скилл — Начни игру на HackerLab

Курс AD