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

Тема в разделе "Lotus - Программирование", создана пользователем JohnLemon, 25 авг 2014.

  1. JohnLemon

    JohnLemon Well-Known Member

    Регистрация:
    20 авг 2014
    Сообщения:
    274
    Симпатии:
    5
    Здравствуйте, подскажите плз как заменить скрипт в data table
    Код (Text):
    return database.getAllDocuments();
    что бы отображались не все документы а только из формы fMain. Делаю по статье Вот Там интересное решение с кнопками но все документы меня не устраивают (
     
  2. lmike

    lmike нет, пердело совершенство
    Команда форума Lotus team

    Регистрация:
    27 авг 2008
    Сообщения:
    6.075
    Симпатии:
    300
    судя по контексту кода - вопрос в xPages
    ЗЫЖ вопщем - правильно задавайте вопросы, уважайте коллег
     
  3. turumbay

    Регистрация:
    13 мар 2009
    Сообщения:
    625
    Симпатии:
    2
    Подозреваю, что
    Код (Text):
    return database.search("Form='fMain'");
     
  4. ty3uk

    ty3uk Well-Known Member

    Регистрация:
    31 мар 2008
    Сообщения:
    169
    Симпатии:
    0
    у меня тупой вопрос всем участвующим. Вот насколько нормально использовать методы класса Search? Я всех своих новых программеров учу не использовать данный способ, а учиться правильно делать вьюхи. Вот для этого случая, к примеру, во всех наших базах есть такой служебное представление (All\ByForm), первая колонка категория по форме. Вот не правильней-ли сделать вот такую вьюху и использовать, что-то вроде
    Код (LotusScript):
    var t_view:NotesView=database.getView("(All\\Byform)");
    var t_col:NotesDocumentCollection=t_view.getAllDocumentsByKey("fMain",true);
    return t_col.getCount()
    и что подобное будет намного быстрее работать, к примеру на базе с 140т.документами (около 10-ти форм) и объёмом около 10гб (в базе, ещё, есть разграничение по видимости, но в данном моменте, его исключим)?
     
  5. JohnLemon

    JohnLemon Well-Known Member

    Регистрация:
    20 авг 2014
    Сообщения:
    274
    Симпатии:
    5
    Спасибо сработало ))) Тут вобще что с форумом как то странно ошибки вваливаются повсюду, а как плюсы ставить ) ?

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

    ty3uk Well-Known Member

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

    lmike нет, пердело совершенство
    Команда форума Lotus team

    Регистрация:
    27 авг 2008
    Сообщения:
    6.075
    Симпатии:
    300
  8. savl

    savl Lotus team
    Lotus team

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

    lmike нет, пердело совершенство
    Команда форума Lotus team

    Регистрация:
    27 авг 2008
    Сообщения:
    6.075
    Симпатии:
    300
    savl я про перформанс - там с цифрами
     
  10. turumbay

    Регистрация:
    13 мар 2009
    Сообщения:
    625
    Симпатии:
    2
    Если коротко - 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">
    Код (Text):
    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 позиций ), то большинство позиций оказываются кэшированными на клиенте и в итоге все "летает"
    В вашем конкретном случае(в предположении, что по заданной форме примерно 14K доков) быстрее работать не будет. Основное время уйдет на обход коллекции. Ну и пример нетиповой: отобрать все доки по заданной форме в базе на 140k доков - это скорее всего какая-то серверная задача(отчет? его можно предвычислять и пользоваться инкрементальными алгоритмами), либо служебный код(который обычно не критичен к времени отклика: рассылки, формирование суточных/недельных/квартальных отчетов, прочие ночные агенты). Конечному пользователю коллекция такого размера обычно не нужна.
     
  11. lmike

    lmike нет, пердело совершенство
    Команда форума Lotus team

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

Поделиться этой страницей