Если база на сервере - работать не будет (только для локальных баз)
На сервере через консоль: updall -F например. Это можно замутить и автоматом, только это бред.
Так как JohnLemon пытается строить интерфейс, не правильно.
-
Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе
На сервере через консоль: updall -F например. Это можно замутить и автоматом, только это бред.
Так как JohnLemon пытается строить интерфейс, не правильно.
Я, уже месяца 2-3 говорю, что Лимончик неправильно всё делает. Он сразу начал работать с доминохой как с релиационкой (да и ломанулся в хпагесы, абсолютно не зная классику, при этом видно что программер из него нулевой. Еслиб он был нормальным программером этоб ещё можно было допустить). Запросы и т.д. Я ещё тогда сказал что это неправильно, на меня набросились что я не прав, что запросы тоже нужны. Ну что? получили? Вот к такому всегда и скатывается. А почему я знал это ещё 3-ри месяца назад? Да потому что я, в нашей конторе, далеко не рядовой программер, помимо того что архитектор всех систем на доминохе, ещё и занимаются обучением новичков, и я сразу вижу, кто сможет программировать в доминохе, а для кого это будет "я на доминохе ничего не получил" (сколько я таких перцов перевидел, просто ппц... Так хочется, иногда, с разворота в морду дать. Говоришь делай так, нетбля, дяденька, я с тремя дипломами, и не нужно мне указывать! А через месяц: а почему у меня не работает?)
Хммм... В моем понимании, такая задача возникает только если создается одновременно большое кол-во практически идентичных документов...
Ну скажем, пришло 100 писем от одного корреспондента, в каждое вложен свой файл договора, а нам надо быстро найти какой-то конкретный договор.
Но такое вообще бывает на практике-то?...
Ну вообще-то работает и на LS (как на клиенте так и на сервере) и на SSJS, но только, если индекс предварительно был создан
Дак я и спрашиваю как правильно сделать и задачу в роде расписал, сказал как сделал я, если прогуглить поиск на xpages или что то подобное в первых рядах примеры с полнотекстовым поиском.
Код:
if (database.isFTIndexed()) {
database.updateFTIndex(false)вот именно по этому, индексы грузят сервер. Также как и грузит сервак большое кол-во вьюх с большим кол-вом колонок. Также сервер сильно грузит большое кол-во документов базах и т.д. И во время обучения, ты этого всего не видишь, т.к. с 10-ть вьюхами по 30-ть колонок и 40-ка документами в базе, всё работает нормально. А вот когда в базе, в бою, документов будет под 10-ть тысяч, вьюх под сотню, а в тяжёлых хпагесах, дополнительно, ты будешь требовать от сервака чтоб он полнотекстовые индексы обновлял (илил, постоянно, в этих индексах искал на каждое действие пользователя). То у тебя повится идея, что доминоха старьё, тормозная, и нифига не работает.
А всё из-за чего? из-за того, что ты пытаешься всё делать "простым способом". Он "простой" для тебя, т.к. у тебя нет опыта. А для сервер он дааалеко не простой.
Да, у сервера есть FT индекс, да можно делать запросы, но, лучше, делать легковесные вьюхи и работать с ними, т.к. скорость сильно разная. Запросы нужно делать только в том случае, если, уже, действительно, другого способа нет (запрос для доминохи, более тормозная фича, чем основной рабочий инструмент). Обрати внимание, что многие тебе говорят что надо по вьюхам работать, по возможности.
Нельзя к доминохе так грубо подходить, это не SQL, если в SQL запросы это единственный рабочий инструмент, и всё делается на запросах, то в Доминохе запрос это вторичный!! Первичный это вьюхи!
Правда напрегает что для выборки в вьюхе все параметры статичные? И видя это, не вникая с какого хрена IBM сделал так, ты используешь запросы. Вот-же оно, решение! IBM-овцы тупые!!!! ТОлько базы заточенны именно под вьюхи с статическим запросом, а не на постоянные поиски в мегатонных индексах. А собственно почему? Да потому, что, данные в Доминохе, не в статичных таблицах (коими они являются в SQL системах) и нет статическогоп онятия что айтем text_22 является текстовым, с размером 30байт. Есть понятие айтема, но он может быть как текстовым, так и числовым и т.д. Размер у него не фиксированный, более того, в нём не одно значение!!! Т.е. разжижая один момент (статичность таблиц) доминоха, чтоб не потерять скорость, усиливает другой момент (статичные запросы). Если "статичные запросы" ослабить, то серваку похренеет.
ещё добавочка... Ты ещё с индексами пробелм не имел. Дале будет интересней. Когда ты в одном документе сделаешь айтем Number=число, а в другом Number=text. Вот тогда будет тебе веселье. Посмотрим как у тебя индексы будут искать по этому айтему. Также, веселье тебе доставят айтемы типа "дата/время".
А всё из-за чего? из-за того, что ты пытаешься всё делать "простым способом". Он "простой" для тебя, т.к. у тебя нет опыта. А для сервер он дааалеко не простой.
Да, у сервера есть FT индекс, да можно делать запросы, но, лучше, делать легковесные вьюхи и работать с ними, т.к. скорость сильно разная. Запросы нужно делать только в том случае, если, уже, действительно, другого способа нет (запрос для доминохи, более тормозная фича, чем основной рабочий инструмент). Обрати внимание, что многие тебе говорят что надо по вьюхам работать, по возможности.
Нельзя к доминохе так грубо подходить, это не SQL, если в SQL запросы это единственный рабочий инструмент, и всё делается на запросах, то в Доминохе запрос это вторичный!! Первичный это вьюхи!
Правда напрегает что для выборки в вьюхе все параметры статичные? И видя это, не вникая с какого хрена IBM сделал так, ты используешь запросы. Вот-же оно, решение! IBM-овцы тупые!!!! ТОлько базы заточенны именно под вьюхи с статическим запросом, а не на постоянные поиски в мегатонных индексах. А собственно почему? Да потому, что, данные в Доминохе, не в статичных таблицах (коими они являются в SQL системах) и нет статическогоп онятия что айтем text_22 является текстовым, с размером 30байт. Есть понятие айтема, но он может быть как текстовым, так и числовым и т.д. Размер у него не фиксированный, более того, в нём не одно значение!!! Т.е. разжижая один момент (статичность таблиц) доминоха, чтоб не потерять скорость, усиливает другой момент (статичные запросы). Если "статичные запросы" ослабить, то серваку похренеет.
ещё добавочка... Ты ещё с индексами пробелм не имел. Дале будет интересней. Когда ты в одном документе сделаешь айтем Number=число, а в другом Number=text. Вот тогда будет тебе веселье. Посмотрим как у тебя индексы будут искать по этому айтему. Также, веселье тебе доставят айтемы типа "дата/время".
Дак может подскажешь как лучше сделать то, или ссылочку на пример, мне нужно поиск просто по нескольким полям во вьюшке одновременно, например по дате и ФИО в двух разных EditBox
а если я тебе скажу что нет такого способа, и едиснтвенный это то что ты делаешь? Твоя реакция?
А теперь, если я скажу, что народ чуть выше говорил, что просто сделать вьюху, и показывать документы разбитые по датам, а там, ещё и по ФИО? Что скажешь? неудобно?
Ты свой мозг всё не можешь переключить с SQL на доминоху, и продолжаешь работать всё также.
ПО дате будет сложно (если, типа, старше 4-го декабря и т.п. т.е. не на точную дату, а с такой-то даты. вообще с условными параметрами будет сложно, типа содержит "ля-ла", менше 5-ти, ранее января), а вот выборку по пользователю, элементарно. Первая колонка категория с именем пользвоателя, Хпагесы позволяют делать выборку из вьюхи по одной категории, туда запихиваешь имя пользователя.
Если дата строгая, то можно делать вьюху с двумя колонками, дата+фио, и, соотвественно, делать выборку дата+фио.
Оба варианта отрабатывают моментально (вру конечно, когда документов будет дофига, там начинается проблема с перестройкой вьюх, видомостью документов и т.д. но это явно работает намного быстрей чем поиск по FT. Кстати, вот с большим кол-вом документов и сложной видимостью, в хпагесах, как не странно, отрабатывает на порядок быстрей чем подобное в классическом вебе. Всё руки не доходят, чтоб клиентам общую вьюху переделать на хпагесы, ато они по две минуты ждут то, что им может показаться за 3-ри секунды...)
сразу, имена пользователей, обычно, идут в формате CN=xx/OU=xx с этим постоянная проблема у новичков. С датами, из хпагесов, тож будут проблемы (в колонке оно в своём формате, с джава скрипта, скорей всего, другой формат). Для начала, попробуй сделать простую выборку из вьюхи (имеется в виду показать сингл категорию) на какойнить простой параметр. Потом проэксперементируй с вложенным вторым параметром. Когда получишь стабильность, переключайся на фио пользвоателя, когда и это заработает, переключайся на фио+дата (хотя, имхоЮ надо наоборот дата+фио, ну это по ситуации).
Обращаю внимание, что выборка по сингл-категори. Как думаешь, что это значит? А значит это, что выборку ты сможешь сделать только для васи, и не сможешь сделать одновременно для васи и пети.
Вложенный синг-категория, это когда для васи+6-тое декабря.
когда это сделаешь, можно наворачивать, к примеру имена не с неба беруться а из списка, а список формируется по первой колонке. Дата-же, зависимая от имени. Когда имя выбрано, то по вьюхе, для сингл-категории имени, берёшь вторую колонку, какие там даты есть. Соотвественно для этого тебе понадобиться две вьюхи. одна ИМЯ(кат)+дата(плоский) и вторая, для конечной выборки Имя(кат)+дата(кат). Не исключаю что и второй вьюхи может хватит на оба способа.
А теперь, если я скажу, что народ чуть выше говорил, что просто сделать вьюху, и показывать документы разбитые по датам, а там, ещё и по ФИО? Что скажешь? неудобно?
Ты свой мозг всё не можешь переключить с SQL на доминоху, и продолжаешь работать всё также.
ПО дате будет сложно (если, типа, старше 4-го декабря и т.п. т.е. не на точную дату, а с такой-то даты. вообще с условными параметрами будет сложно, типа содержит "ля-ла", менше 5-ти, ранее января), а вот выборку по пользователю, элементарно. Первая колонка категория с именем пользвоателя, Хпагесы позволяют делать выборку из вьюхи по одной категории, туда запихиваешь имя пользователя.
Если дата строгая, то можно делать вьюху с двумя колонками, дата+фио, и, соотвественно, делать выборку дата+фио.
Оба варианта отрабатывают моментально (вру конечно, когда документов будет дофига, там начинается проблема с перестройкой вьюх, видомостью документов и т.д. но это явно работает намного быстрей чем поиск по FT. Кстати, вот с большим кол-вом документов и сложной видимостью, в хпагесах, как не странно, отрабатывает на порядок быстрей чем подобное в классическом вебе. Всё руки не доходят, чтоб клиентам общую вьюху переделать на хпагесы, ато они по две минуты ждут то, что им может показаться за 3-ри секунды...)
сразу, имена пользователей, обычно, идут в формате CN=xx/OU=xx с этим постоянная проблема у новичков. С датами, из хпагесов, тож будут проблемы (в колонке оно в своём формате, с джава скрипта, скорей всего, другой формат). Для начала, попробуй сделать простую выборку из вьюхи (имеется в виду показать сингл категорию) на какойнить простой параметр. Потом проэксперементируй с вложенным вторым параметром. Когда получишь стабильность, переключайся на фио пользвоателя, когда и это заработает, переключайся на фио+дата (хотя, имхоЮ надо наоборот дата+фио, ну это по ситуации).
Обращаю внимание, что выборка по сингл-категори. Как думаешь, что это значит? А значит это, что выборку ты сможешь сделать только для васи, и не сможешь сделать одновременно для васи и пети.
Вложенный синг-категория, это когда для васи+6-тое декабря.
когда это сделаешь, можно наворачивать, к примеру имена не с неба беруться а из списка, а список формируется по первой колонке. Дата-же, зависимая от имени. Когда имя выбрано, то по вьюхе, для сингл-категории имени, берёшь вторую колонку, какие там даты есть. Соотвественно для этого тебе понадобиться две вьюхи. одна ИМЯ(кат)+дата(плоский) и вторая, для конечной выборки Имя(кат)+дата(кат). Не исключаю что и второй вьюхи может хватит на оба способа.
Что-то "курил курил" и не очень понял. Дайте мне высказаться. 
Сделать вхождение даже по индексированной колонке во вьюхе не получится. Если надо вхождение в поле, то только полнотекстовый поиск по индексу, который обновляется не моментально. Если устраивает вариант значение "начинается с" или "равно", то можно использовать вьюху. Это было про текстовые значения колонок.
Теперь про даты. Делаем колонку типа дата во вьюхе и можно искать по диапазону, если использовать NotesDateRange class для поиска.
Если сложить во вьюхе 2 колонки, первая - ФИО, вторая - ДАТА, то можно по вьюхе сделать выборку по "ФИО равно" и "ДАТА в диапазоне".
Как-то так. Но после SQL всегда хочется нормальных запросов, но в Лотусе этого никогда не было, нету и не будет. У него другое предназначение. Зато как Лотус быстро работает при 700к разноформатных документов внутри, просто загляденье.
Сделать вхождение даже по индексированной колонке во вьюхе не получится. Если надо вхождение в поле, то только полнотекстовый поиск по индексу, который обновляется не моментально. Если устраивает вариант значение "начинается с" или "равно", то можно использовать вьюху. Это было про текстовые значения колонок.
Теперь про даты. Делаем колонку типа дата во вьюхе и можно искать по диапазону, если использовать NotesDateRange class для поиска.
Если сложить во вьюхе 2 колонки, первая - ФИО, вторая - ДАТА, то можно по вьюхе сделать выборку по "ФИО равно" и "ДАТА в диапазоне".
Как-то так. Но после SQL всегда хочется нормальных запросов, но в Лотусе этого никогда не было, нету и не будет. У него другое предназначение.
Зато как Лотус быстро работает при 700к разноформатных документов внутри, просто загляденье. блиииин... мойте мозги порошкоооом!!!!
Вот блин, в мозгу с самого начала лежало что только по одному значению, до DateRange objects как-то глаза не доходили... Надо попробовать.
А вчем проблема с
Он что каждый раз все индексы заного обновляет ?? Нельзя сделать что бы он обновлял только не индексированные доки???
а в чём проблема:
если (договор_с_уборщицей.существует){убрать мусор офисе}
т.е. вызываем уборщицу, она приходит, смотрит по сторонам, всех дёргает, требует ноги поднять, потом ей знакомая позвонит, она поболтает, потом ещё походит и скажет: "у вас чисто, ничего убирать не надо".
Лишние действия на пустом месте не нужно городить!
Тебе курсач сдать или ты базу делаешь?
если (договор_с_уборщицей.существует){убрать мусор офисе}
т.е. вызываем уборщицу, она приходит, смотрит по сторонам, всех дёргает, требует ноги поднять, потом ей знакомая позвонит, она поболтает, потом ещё походит и скажет: "у вас чисто, ничего убирать не надо".
Лишние действия на пустом месте не нужно городить!
Тебе курсач сдать или ты базу делаешь?
ну так тебе уже неоднократно сказали, отходи от индексов. Ты сервак вот такими скриптами будешь мучать. Если на каждое обновление страницы в вебе, он будет индексы пересчитывать. По началу будет нормально работать, а потом будет момент, что сервак у тебя начнёт тормозить всё сильней и сильней. И ты не будешь понимать из-за чего, и про эту базу, давно, забудешь. А у кого-то это будет основным иснтрументом. А ещё, парочку такойже фигни ещё гденить повешаешь, и начнётся веселье, т.к. не сможешь определить в каком месте у тебя сервак проседает.
Если так сильно хочется, то ставь рядом скул, делай там базу. В документах, на постсаве вешай скрипт, который лезет в скул и создаёт/меняет там запись. На хпагесах сделай спец интерйфейс, где запрос будет идти не в доминошную базу а в скул. Туда даёшь запрос по параметрам, тебе возращается список UNID-ов документов (или униды + несколько "важных" полей для "представления"), по этим унидам строишь табличку. И при нажатии на элемент, уже, открывается документ из базы (у тебяж унид есть).
Мы подобное делали, когда делали демку для риэлторов. Там данные постоянно менялись + такие многоэтажные и сложные запросы были, что реальность их выполнения на доминошных индексах, просто нереальна (по причине того чтозапрос очень большой с бешенными условиями + вероятность того что в выборку попадёт новый/изменёный документ очень мала), сделали на скуле, скорость отработки была моментальная (и это учитывая что доминоха стояла в офисе, а скуловская база у меня дома).
Как работать с скулом? смотри в сторону JDBC. В интеренет есть примеры работы с скулом с хпагесов.
добавочка: а хпагесы ты как гоняешь? через веб интерфейс или через лотуса? Просто вот такой режим как я описал, он нормален для веба, для чистых лотусов, могут быть нехилые проблемы с безопасностью...
Если так сильно хочется, то ставь рядом скул, делай там базу. В документах, на постсаве вешай скрипт, который лезет в скул и создаёт/меняет там запись. На хпагесах сделай спец интерйфейс, где запрос будет идти не в доминошную базу а в скул. Туда даёшь запрос по параметрам, тебе возращается список UNID-ов документов (или униды + несколько "важных" полей для "представления"), по этим унидам строишь табличку. И при нажатии на элемент, уже, открывается документ из базы (у тебяж унид есть).
Мы подобное делали, когда делали демку для риэлторов. Там данные постоянно менялись + такие многоэтажные и сложные запросы были, что реальность их выполнения на доминошных индексах, просто нереальна (по причине того чтозапрос очень большой с бешенными условиями + вероятность того что в выборку попадёт новый/изменёный документ очень мала), сделали на скуле, скорость отработки была моментальная (и это учитывая что доминоха стояла в офисе, а скуловская база у меня дома).
Как работать с скулом? смотри в сторону JDBC. В интеренет есть примеры работы с скулом с хпагесов.
добавочка: а хпагесы ты как гоняешь? через веб интерфейс или через лотуса? Просто вот такой режим как я описал, он нормален для веба, для чистых лотусов, могут быть нехилые проблемы с безопасностью...
Обучение наступательной кибербезопасности в игровой форме. Начать игру!