Datatable Отобразить Документы

[JohnLemon]

Здравствуйте, подскажите плз как заменить скрипт в data table

return database.getAllDocuments();

что бы отображались не все документы а только из формы fMain. Делаю по статье

Ссылка скрыта от гостей

Там интересное решение с кнопками но все документы меня не устраивают (

 

[lmike]

судя по контексту кода - вопрос в xPages
ЗЫЖ вопщем - правильно задавайте вопросы, уважайте коллег

 

[turumbay]

что бы отображались не все документы а только из формы fMain.

Подозреваю, что

return database.search("Form='fMain'");

 

[ty3uk]

у меня тупой вопрос всем участвующим. Вот насколько нормально использовать методы класса Search? Я всех своих новых программеров учу не использовать данный способ, а учиться правильно делать вьюхи. Вот для этого случая, к примеру, во всех наших базах есть такой служебное представление (All\ByForm), первая колонка категория по форме. Вот не правильней-ли сделать вот такую вьюху и использовать, что-то вроде

var t_view:NotesView=database.getView("(All\\Byform)");
var t_col:NotesDocumentCollection=t_view.getAllDocumentsByKey("fMain",true);
return t_col.getCount()

и что подобное будет намного быстрее работать, к примеру на базе с 140т.документами (около 10-ти форм) и объёмом около 10гб (в базе, ещё, есть разграничение по видимости, но в данном моменте, его исключим)?

 

[JohnLemon]

Подозреваю, что

return database.search("Form='fMain'");

Спасибо сработало ))) Тут вобще что с форумом как то странно ошибки вваливаются повсюду, а как плюсы ставить ) ?

Добавлено:

у меня тупой вопрос всем участвующим. Вот насколько нормально использовать методы класса Search? Я всех своих новых программеров учу не использовать данный способ, а учиться правильно делать вьюхи. Вот для этого случая, к примеру, во всех наших базах есть такой служебное представление (All\ByForm), первая колонка категория по форме. Вот не правильней-ли сделать вот такую вьюху и использовать, что-то вроде

var t_view:NotesView=database.getView("(All\\Byform)");
var t_col:NotesDocumentCollection=t_view.getAllDocumentsByKey("fMain",true);
return t_col.getCount()

и что подобное будет намного быстрее работать, к примеру на базе с 140т.документами (около 10-ти форм) и объёмом около 10гб (в базе, ещё, есть разграничение по видимости, но в данном моменте, его исключим)?

Такой вариант посмотрю позже, пока разбираюсь... ((

 

[ty3uk]

JohnLemon, я не зря спросил свой вопрос, дело в том, что я считаю что поиск по базе (в т.ч. и с полнотекстовым индексом) не совсем правильно, и является достаточно медленным (иногда на порядки). На малых объёмах это не заметно, а вот когда база работает уже у клиента, начинаются вопросы по поводу тормозов и т.п. Вот и родился вопрос для Гуру, я прав или нет.
Понятно что иногда есть моменты, когда вьюхами не обойтись, и надо делать именно полноценный запрос, но народ, слишком часто, использует запросы на простейшие вещи. У меня во всех базах, к примеру, есть три служебные вьюхи, это по форме, по ID-документа и по ParentID документа. Потребности перекрывает процентов на 90%. Т.е. в 90% случаев используется быстрый способ поиска, и не перелапачивание всех документов в базе. Но, может я и не прав, ждём что народ скажет.
А в конкретно вашем случае, очень похоже на то, что вы решили попрограммировать в ХПагесах, но не очень представляете как устроена доминоха и особенностей её работы. Честно говоря не знаю куда вас это заведёт. То что я привёл, это переделанный под JS простейший ЛотусСкрипт. В свою очередь, уже на первых шагах вы используете запросы поиска, но они не очень специфичны для Домино (и, имхо, крайне не производительные), они хорошо работают на SQL базах (коей не является СУБД Домино).

 

[lmike]

Ty3uK отвечу сюда

Ссылка скрыта от гостей

 

[savl]

Ty3uK
Да я тоже вьюхи использую, отобразить кучу документов из другой базы в текущем документе? - вьюха.
Получить документ по UNID? - вьюха.
Получить все ответные на всех уровнях цепочки документа? - вьюха.
Сделать рассылку по сроку действия? - вьюха
Везде подряд не использую - неоправданно, где то-то и Search сделаю.
lmike
Да, хорошая тема, но мне пока не пригодилась.

 

[lmike]

savl я про перформанс - там с цифрами

 

[turumbay]

у меня тупой вопрос всем участвующим. Вот насколько нормально использовать методы класса Search? Я всех своих новых программеров учу не использовать данный способ, а учиться правильно делать вьюхи.

Если коротко - it depends.
<div class="sp-wrap"><div class="sp-head-wrap"><div class="sp-head folded clickable">Развернуто</div></div><div class="sp-body"><div class="sp-content">
Вьюха - дорогое удовольствие, и на нагруженной системе она зачастую протухшая(неактуальная).
Делаю вьюху только если реально упираюсь в производительность. В общем случае, search работает крайне быстро(правда есть известные проблемы с поиском при наличии окурков в базе ).
В случае, когда код выполняется на клиенте, а в коллекции много документов - разница слабоуловима, т.к. основное время тратится не на поиск, а на обход коллекции клиентом.
Если предполагается, что в коллекции будет много документов - я предпочту search. Если миллионная база, а в результаты поиска попадет 5-10 доков , то, возможно, сделаю вьюху.
Есть большая коллекция документов, и для каждого дока в коллекции нужен лукап в другую базу - тут лучше вьюху: тыща view.getDocumentByKey значительно выиграет у тыщи db.search(но опять же, при условии, что не переполучаем вьюху тыщу раз).
В общем тема нетривиальная, и правильный ответ: it depends. Ну и нельзя забывать классику про "преждевременную оптимизацию"

История 1:
Серверный агент строит отчет, база полмиллиона доков, на выходе генерица xml. Работает крайне медленно. Проблема в db.search? В большом количестве доков? Отнюдь! Проблема в том, что для формирования xml используется конкатенация строк: xml = xml + .... Замена string на stream - и время работы сократилось в четыре(!) раза

История 2:
Пользователи регулярно выполняют поиск товара в каталоге(30K документов): на входе строка, на выходе - достаточно сложный поисковый запрос по нескольким полям. Пользователи на плохом канале жалуются, что "все тормозит". Расследование показывает, что сам db.search выполняется мнгновенно ( < 1 сек ), что неудивительно, ибо search всегда выполняется на сервере и от ширины канала не зависит. Проблема - долгий обход коллекции на клиенте. Решение: использование недокументированного collection.getNoteIds и кэширование документов(точнее объектов, считанных из документов) на клиенте. <div class="sp-wrap"><div class="sp-head-wrap"><div class="sp-head folded clickable">class GoodsRepo</div></div><div class="sp-body"><div class="sp-content">

Private cache List As ProductInfo '' use noteid as keys

Public Function search(query As String) As SearchResponse
.....
Set collection = t_db.Search( sf$, Nothing, 0 )
If collection.Count > 0 Then
Forall noteId In collection.getNoteIds()
If Not Iselement(cache(noteId)) Then
Set cache(noteId) = '' получили док по NoteId, сформировали экземпляр GoodInfo
End If
Call response.add(cache(noteId))
End Forall
End If
Set search = response
End Function

Результат: т.к. обычно ищут примерно одно и тоже ( актуальное наличие ~ 1000 позиций ), то большинство позиций оказываются кэшированными на клиенте и в итоге все "летает"

и что подобное будет намного быстрее работать, к примеру на базе с 140т.документами (около 10-ти форм) и объёмом около 10гб (в базе, ещё, есть разграничение по видимости, но в данном моменте, его исключим)?

В вашем конкретном случае(в предположении, что по заданной форме примерно 14K доков) быстрее работать не будет. Основное время уйдет на обход коллекции. Ну и пример нетиповой: отобрать все доки по заданной форме в базе на 140k доков - это скорее всего какая-то серверная задача(отчет? его можно предвычислять и пользоваться инкрементальными алгоритмами), либо служебный код(который обычно не критичен к времени отклика: рассылки, формирование суточных/недельных/квартальных отчетов, прочие ночные агенты). Конечному пользователю коллекция такого размера обычно не нужна.

 

[lmike]

есть ситуация, когда "вот так" - получают некую коллекцию (в цикле) и по каждому доку из коллекции ищут другую коллекцию (видел такие системы)
таки да - таких ситуаций желательно избегать, или (если это отчет) выгружать "все" в РСУБД и там строить реляции
часто - это "болезнь" людей пришедших в LDN с др. БД
правда бывают ситуации, когда по бизнес-процессу выгрузить никак а строить соотношения нужно
в таких случаях вызов в цикле db.search будет существенным по накладным расходам