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

[Akupaka]

Например так

ну, т.е. без дефолта. понятно. пасиб.

 

[oshmianski]

Мы перед селектом вьюхи делали DEFAULT $Ref:=myParent;
Работало, так как в документах $Ref отсутствовало.
С вариантом Field $REF не экспериментировали

если в доке есть родной $REF, то вариант с myParent не прокатит!
по крайней мере у меня не прокатило

 

[Medevic]

Можно "удалить" $REF.
@SetField("$Ref"; @DeleteField)

 

[Akupaka]

если в доке есть родной $REF, то вариант с myParent не прокатит!

не прокатит, дефолт работает только, если поля нету в документе

Можно "удалить" $REF.

это, кажися, не сработает

 

[oshmianski]

Можно "удалить" $REF.
@SetField("$Ref"; @DeleteField)

и разрушить иерархию на родных $REF, если уже используется?
я так понял, можно юзать или $REF или свою альтернативную.
одновременно не получится

 

[hosm]

oshmianski
Уточняю: Не прокатит вариант из-за DEFAULT!
Парент это или не парент, тут вообще не имеет значения.
DEFAULT работает, только если поля нет и не добавляет поле в документ.
Об отсутствии дочерних я явно упоминала при описании решения.
Если поле есть, думаю, его можно перебить с помощью варианта TIA.
Вопрос только - нужно ли, поле ж тогда сохранится в доке?
Вообще кто-то использовал его вариант, он рабочий?

 

[Akupaka]

нужно ли, поле ж тогда сохранится в доке?

не сохранится

 

[ToxaRat]

и разрушить иерархию на родных $REF, если уже используется?
я так понял, можно юзать или $REF или свою альтернативную.
одновременно не получится

можно и так и так но по правильному лучше проектировать базу БЕЗ респонсов, тогда можно на базе поставить флажок "не поддерживать иеархию" что существенно скажется на производительности

 

[Akupaka]

тогда можно на базе поставить флажок "не поддерживать иеархию" что существенно скажется на производительности

мдя? тесты и другие доказательства?

 

[hosm]

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

поверим твоему опыту, это меня сегодня глючит...
А если поизвращаться - так что получится, если мультивалью?
FIELD $Ref := @If(@IsAvailable(MyRef) & @IsAvailable($Ref); MyRef:$Ref; $Ref);

 

[TIA]

А если поизвращаться - так что получится, если мультивалью?

Нет. Не получится.

 

[ToxaRat]

мдя? тесты и другие доказательства?

А что админского хелпа вам уже не достаточно?

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.

 

[hosm]

TIA
Получится "нет". или не получится.
В общем, что получится или не получится в итоге, я не понял :google:
Лана, пока извраты отставим - примем как аксиому, что мультизначное $Ref будет некорректно обрабатываться в представлении.
*Просто интересно было, как отреагирует на такую конструкцию, что и как отобразится в представлении.*

 

[TIA]

можно и так и так но по правильному лучше проектировать базу БЕЗ респонсов,

Гораздо больше выигрыш в производительности получится, если БД спроектировать так, чтоб документы были общедоступными.
Возьмите это себе за правило и никогда не используйте разграничение доступа к документам.
Ещё возьмите за правило иметь в БД строго одну вьюшку. Надо было бы и от неё отказаться, но Нотес не позволит.
Агенты -- зло ибо грузят сервер. Документ в БД -- строго один, а то в производительности потеряем.


Добавлено:

Получится "нет". или не получится.

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

 

[ToxaRat]

TIA

Вобщем, многозначность $REF не приводит к желаемому эффекту -- отображению одного и того же документа респонсом сразу под несколькими документами в одном и том же представлении. Как именно повлияет -- не помню, вобщем ничего полезного.

ну например подвесит индексер а тот положит сервер

 

[TIA]

ну например подвесит индексер а тот положит сервер

Неужто ты попробовал?

 

[ToxaRat]

TIA
даже пробывал создавать несколько одноименных итемов $REF
за 10 лет с лотусом много чего приходилось пробывать