Последний параметр метода Search не работает?

[IsAvailable]

Неожиданно столкнулся вот с какой проблемой: получаю коллекцию методом Search, указываю последний параметр, скажем = 10, получаю коллекцию из 10 документов, но когда иду по этой коллекции, то там ВСЕ документы, удовлетворяющие условию!!!

Set coll = fdb.Search({<условие>, Nothing, 10)
Print "alldocs: " & Cstr(coll.Count)
' выводит "alldocs: 10"
Set fdoc = coll.GetFirstDocument
i = 0
While Not(fdoc Is Nothing)
i = i + 1
Print "iteration # " & Cstr(i)
Call ws.CurrentDocument.FieldAppendText("<имя поля>", "<строка со значениями из fdoc>")
Set fdoc = coll.GetNextDocument(fdoc)
Wend
' выводит пока не забьется поле на 32К или пока не закончатся все документы, удовлетворяющие <условию>

Может просто понедельничный тупняк у меня? ) Может, знает кто, в чем тут дело?
В хэлпе написано четко, ясно, без примечаний - последний параметр - число документов, которое я хочу получить в коллекцию:

Integer. The maximum number of documents you want returned. Specify 0 to receive all matching documents.

 

[hosm]

муж мой вроде сталкивался с похожей траблой. глюка?

 

[turumbay]

Неожиданно столкнулся вот с какой проблемой: получаю коллекцию методом Search, указываю последний параметр, скажем = 10, получаю коллекцию из 10 документов, но когда иду по этой коллекции, то там ВСЕ документы, удовлетворяющие условию!!!
В хэлпе написано четко, ясно, без примечаний - последний параметр - число документов, которое я хочу получить в коллекцию:

Ага. Редкий случай, когда хэлп врет.
Последний параметр db.search - не работает. collection.count кажет правильное значение, но реально в коллекции есть все документы. И трафик от сервера, и время поиска - все будет одинаково. Т.е. параметр ни на что не влияет, и даже вреден, ибо вводит в заблуждение.

 

[hosm]

так надо айбиэмцам сказать, пусть правят, что ж они так народ в заблуждение вводят

 

[turumbay]

так надо айбиэмцам сказать, пусть правят, что ж они так народ в заблуждение вводят

они в курсе:

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

 

[hosm]

класс, так эта багофича еще с древних времен

 

[IsAvailable]

Ясно, ИБМ в своем стиле
Спасибо всем откликнувшимся : )

PS В натуре, надо им в саппорт написать...

 

[ToxaRat]

лучше вообще от подобного сеча уйта
я тут недавно вообще с ним чуть не убился
если запустить один агент с сечем то будет 5 секунд на такой сеачь
а вот если 4е агента одновременно то будет по 10 минут каждому на сеачь,
в общем на последних версиях домино сеарч єто убийца...

 

[Omh]

ToxaRat
А чем заменить?
FTSearch'ем?

 

[Akupaka]

если запустить один агент с сечем то будет 5 секунд на такой сеачь
а вот если 4е агента одновременно то будет по 10 минут каждому на сеачь,

Одну задачу Антон может выполнять 5 мин. А две одновременно - 10 минут. Сходства не находишь?

А чем заменить?
FTSearch'ем?

Либо поиском по виду. Других вариантов и нед.
С ФТ-поиском, кстати, свои баги. Типа форматы дат и т.п.

 

[ToxaRat]

Akupaka

Одну задачу Антон может выполнять 5 мин. А две одновременно - 10 минут. Сходства не находишь?

разницу между 5 секундами и 10 минутами чувствуешь?

Omh

А чем заменить?
FTSearch'ем?

сам сейчас в просрации, заменить нечем, лупить кучу видов не выход
очень надеюсь что это глюк 8.5.1фп3
иначе придется читать заново про нсф_поол и т.д. что-то подсказывает что несколько сечей да еще и по разным базам требует некую монопольность по диску...

 

[VladSh]

Этот последний параметр и нафиг не нужен.
Во-1, где такое может использоваться? Какая область применения?
Во-2, всё равно будешь делать цикл, вот там можно и выйти, если счётчик больше необходимого.

 

[Akupaka]

Во-1, где такое может использоваться? Какая область применения?

Опытным путем определено, что автоматический агент может обработать не более десяти докУментов за запуск.
При оптимизированом поиске по БД, нет смысла обрабатывать (поиском) все документы БД (например, тыщу), если нужный десяток уже определен (например, еще в первой сотне).

 

[VladSh]

Опытным путем определено, что автоматический агент может обработать не более десяти докУментов за запуск.

Что такое "автоматический агент"? Первый раз такое слышу...

При оптимизированом поиске по БД, нет смысла обрабатывать (поиском) все документы БД (например, тыщу), если нужный десяток уже определен (например, еще в первой сотне).

А как можно быть уверенным, что "нужный десяток уже в первой сотне"?
При оптимизированном поиске или вьюхи правильно отстраиваются или формулы поиска для Search правильно пишутся, чтобы не отбирались лишние документы...

 

[IsAvailable]

VladSh
Не нужно быть столь категоричным. Я вот тоже за несколько лет программирования в Lotus захотел воспользоваться этим параметром лишь в первый раз. Но это еще ни о чем не говорит.
На самом деле довольно полезный параметр, когда параметры поиска динамические и заранее не определены (например, вводятся пользователем), а данные нужно отображать в поле (у которого, как известно, лимит в 32кб данных)
Безусловно, проблема эта решается циклом и доп.переменными, но дело-то не в этом. Дело в том, что имеющийся функционал не работает так, как должен работать (а уж для чего он может пригодиться - это дело десятое)

Akupaka
В смысле? Шедульный агент не может обработать больше 10 документов?! Что за ересь? % ))) Или я что-то не так понял? )))

 

[hosm]

может, у него такая сложная обработка и таймаут для агентов. А вообще, плз, поясни, Akupaka, что это было, на базе чего был получен такой опыт.

 

[Мыш]

Search, вроде бы, создает что-то вроде временного вида с указаной формулой отбора. Так что, в некотором смысле, логично, что параметр не работает - в вид-то первые 10 документов не отберешь

 

[nvyush]

Search, вроде бы, создает что-то вроде временного вида с указаной формулой отбора. Так что, в некотором смысле, логично, что параметр не работает - в вид-то первые 10 документов не отберешь

Но серверу не обязательно отдавать все отобранные документы. Пусть возвращает, сколько затребовали.

 

[VladSh]

На самом деле довольно полезный параметр, когда параметры поиска динамические и заранее не определены (например, вводятся пользователем), а данные нужно отображать в поле (у которого, как известно, лимит в 32кб данных)

Это разве не задача разработчика правильно сформировать фильтр поиска, т.е. составить формулу, чтобы не отбирать лишнее?
Если данных больше, чем 32кб, это разве не задача разработчика правильно разложить данные?

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

Дело в том, что он как раз может не работать из-за того, что не для чего ему пригодиться ))) т.к. атавизм.

Но серверу не обязательно отдавать все отобранные документы. Пусть возвращает, сколько затребовали.

Т.е. нам фактически до фонаря, какие 10 он возвратит из 10-ти тысяч??? И потом мы будет куда-то записывать или изменять эти данные? Да!... вот это логика приложения...

Этот параметр нужен разве что для сайтов знакомств )))
а в бизнес-приложениях, хоть у нас это и довольно гибкая платформа, но, думаю, что всё-таки нужны более весомые параметры, чем "отобрать 10 штук нафонарь".

 

[Akupaka]

Что такое "автоматический агент"?

Издеваешсо, да? К примеру, шедульный. Вот кто-то пишет шедульный агент по обработке некоторых документов в базе, и пытается его оптимизировать, чтобы он делал не больше, чем может, чем ему нужно за раз.

А как можно быть уверенным, что "нужный десяток уже в первой сотне"?

Да нет никакой уверенности. Я говорю для примера. Конечно, десятый док может оказаться последним проверяемым в базе, тогда "оптимизации не вышло" ))

При оптимизированном поиске

Влад, ты просил область приминения, я тебе должен был придумать супер сложный пример? ))

Что за ересь?

Ты что-то не так...

Добавлено:

может, у него такая сложная обработка и таймаут для агентов

А мне казалось ты меня плохо знаешь

в вид-то первые 10 документов не отберешь

Почему же? Реляционные БД с этим справляются на ура, а домино как обычно.

Добавлено:

Но серверу не обязательно отдавать все отобранные документы

Мало того, серверу не обязательно искать ВСЕ документы в базе, чтобы вернуть только 10 затребованных, особенно, если эти десять уже были найдены, например, после проверки лишь 20% всех данных. Влад, есть возражения?

Добавлено:

Это разве не задача разработчика правильно сформировать фильтр поиска, т.е. составить формулу, чтобы не отбирать лишнее?

Ой-ей... Большинство задач лотусиста сводится к исправлению глюков платформы, "чтоб работало как надо".

Добавлено:

Дело в том, что он как раз может не работать из-за того, что не для чего ему пригодиться

Тебе нужны страусиные яйца? Мне нет. А вот страусу без них никак...

Добавлено:

Т.е. нам фактически до фонаря, какие 10 он возвратит из 10-ти тысяч?
...
Этот параметр нужен разве что для сайтов знакомств

"Да-да! Я знаю! Меня возьми!" (с) Шрек. Реплика Осла.
А я тебе задачу описал, а ты не вник. Давай еще раз - агент не может обработать за запуск более, к примеру, 10 документов. Зачем ему доставать больше?
...
А даже, если и так? Лотус на столько крут, что программы типа сайта знакомств не его удел?