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

@ysovoytobty · Регистрация: 15.12.2006

Author24 — интернет-сервис помощи студентам

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

LotusScript

Set coll = fdb.Search({<условие>, Nothyng, 10)
Print "alldocs: " & Cstr(coll.Count)
выводит "alldocs: 10"
Set fdoc = coll.GetFirstDocument
i = 0
While Not(fdoc Is Nothyng)
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 · 11.07.2010, 14:45

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

@turumboy · 11.07.2010, 14:47

Сообщение от IsAvailable

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

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

@hosm · 11.07.2010, 14:51

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

@turumboy · 11.07.2010, 14:55

Сообщение от OKEN

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

они в курсе: http://www-01.ibm.com/support/docview.wss?uid=swg21094421

@hosm · 11.07.2010, 14:59

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

@ysovoytobty · 11.07.2010, 15:00

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

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

@ToxoRot · 11.07.2010, 15:02

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

@Omh · 11.07.2010, 15:26

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

@okupoko · 11.07.2010, 15:43

Сообщение от ToxaRat

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

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

Сообщение от Omh

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

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

@ToxoRot · 11.07.2010, 16:00

Akupaka

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

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

Omh

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

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

@VtodSh · 11.07.2010, 19:42

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

@okupoko · 12.07.2010, 01:04

Сообщение от VladSh

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

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

@VtodSh · 12.07.2010, 15:05

Сообщение от Akupaka

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

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

Сообщение от Akupaka

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

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

@ysovoytobty · 12.07.2010, 15:17

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

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

@hosm · 12.07.2010, 15:32

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

@ныш · 12.07.2010, 16:12

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

@mvyush · 12.07.2010, 16:18

Сообщение от Мыш

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

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

@VtodSh · 12.07.2010, 16:35

Сообщение от IsAvailable

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

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

Сообщение от IsAvailable

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

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

Сообщение от nvy

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

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

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

@okupoko · 12.07.2010, 17:03

Сообщение от VladSh

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

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

Сообщение от VladSh

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

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

Сообщение от VladSh

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

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

Сообщение от IsAvailable

Что за ересь?

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

Добавлено:

Сообщение от OKEN

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

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

Сообщение от Мыш

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

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

Добавлено:

Сообщение от nvy

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

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

Добавлено:

Сообщение от VladSh

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

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

Добавлено:

Сообщение от VladSh

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

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

Добавлено:

Сообщение от VladSh

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

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

@okupoko 0 / 0 / 0 Регистрация: 04.10.2007 Сообщений: 2,977
	12.07.2010, 01:04	13
	Сообщение от VladSh Во-1, где такое может использоваться? Какая область применения? Опытным путем определено, что автоматический агент может обработать не более десяти докУментов за запуск. При оптимизированом поиске по БД, нет смысла обрабатывать (поиском) все документы БД (например, тыщу), если нужный десяток уже определен (например, еще в первой сотне). 0

@hosm 0 / 0 / 0 Регистрация: 15.05.2009 Сообщений: 1,454
	11.07.2010, 14:45	2
	муж мой вроде сталкивался с похожей траблой. глюка? 0

@turumboy 0 / 0 / 0 Регистрация: 15.03.2009 Сообщений: 615
	11.07.2010, 14:47	3
	Сообщение от IsAvailable Неожиданно столкнулся вот с какой проблемой: получаю коллекцию методом Search, указываю последний параметр, скажем = 10, получаю коллекцию из 10 документов, но когда иду по этой коллекции, то там ВСЕ документы, удовлетворяющие условию!!! В хэлпе написано четко, ясно, без примечаний - последний параметр - число документов, которое я хочу получить в коллекцию: Ага. Редкий случай, когда хэлп врет. Последний параметр db.search - не работает. collection.count кажет правильное значение, но реально в коллекции есть все документы. И трафик от сервера, и время поиска - все будет одинаково. Т.е. параметр ни на что не влияет, и даже вреден, ибо вводит в заблуждение. 0

@hosm 0 / 0 / 0 Регистрация: 15.05.2009 Сообщений: 1,454
	11.07.2010, 14:51	4
	так надо айбиэмцам сказать, пусть правят, что ж они так народ в заблуждение вводят 0

@turumboy 0 / 0 / 0 Регистрация: 15.03.2009 Сообщений: 615
	11.07.2010, 14:55	5
	Сообщение от OKEN так надо айбиэмцам сказать, пусть правят, что ж они так народ в заблуждение вводят они в курсе: http://www-01.ibm.com/support/docview.wss?uid=swg21094421 0

@hosm 0 / 0 / 0 Регистрация: 15.05.2009 Сообщений: 1,454
	11.07.2010, 14:59	6
	класс, так эта багофича еще с древних времен 0

@ysovoytobty 0 / 0 / 0 Регистрация: 15.12.2006 Сообщений: 202
	11.07.2010, 15:00	7
	Ясно, ИБМ в своем стиле Спасибо всем откликнувшимся : ) PS В натуре, надо им в саппорт написать... 0

@ToxoRot 0 / 0 / 0 Регистрация: 04.11.2007 Сообщений: 3,019
	11.07.2010, 15:02	8
	лучше вообще от подобного сеча уйта я тут недавно вообще с ним чуть не убился если запустить один агент с сечем то будет 5 секунд на такой сеачь а вот если 4е агента одновременно то будет по 10 минут каждому на сеачь, в общем на последних версиях домино сеарч єто убийца... 0

@Omh 0 / 0 / 1 Регистрация: 30.06.2007 Сообщений: 2,153
	11.07.2010, 15:26	9
	ToxaRat А чем заменить? FTSearchем? 0

@okupoko 0 / 0 / 0 Регистрация: 04.10.2007 Сообщений: 2,977
	11.07.2010, 15:43	10
	Сообщение от ToxaRat если запустить один агент с сечем то будет 5 секунд на такой сеачь а вот если 4е агента одновременно то будет по 10 минут каждому на сеачь, Одну задачу Антон может выполнять 5 мин. А две одновременно - 10 минут. Сходства не находишь? Сообщение от Omh А чем заменить? FTSearchем? Либо поиском по виду. Других вариантов и нед. С ФТ-поиском, кстати, свои баги. Типа форматы дат и т.п. 0

@ToxoRot 0 / 0 / 0 Регистрация: 04.11.2007 Сообщений: 3,019
	11.07.2010, 16:00	11
	Akupaka Одну задачу Антон может выполнять 5 мин. А две одновременно - 10 минут. Сходства не находишь? разницу между 5 секундами и 10 минутами чувствуешь? Omh А чем заменить? FTSearchем? сам сейчас в просрации, заменить нечем, лупить кучу видов не выход очень надеюсь что это глюк 8.5.1фп3 иначе придется читать заново про нсф_поол и т.д. что-то подсказывает что несколько сечей да еще и по разным базам требует некую монопольность по диску... 0

	12.07.2010, 17:03

Опции темы

@VtodSh 1 / 1 / 0 Регистрация: 07.12.2009 Сообщений: 1,197
	11.07.2010, 19:42	12
	Этот последний параметр и нафиг не нужен. Во-1, где такое может использоваться? Какая область применения? Во-2, всё равно будешь делать цикл, вот там можно и выйти, если счётчик больше необходимого. 0

@VtodSh 1 / 1 / 0 Регистрация: 07.12.2009 Сообщений: 1,197
	12.07.2010, 15:05	14
	Сообщение от Akupaka Опытным путем определено, что автоматический агент может обработать не более десяти докУментов за запуск. Что такое "автоматический агент"? Первый раз такое слышу... Сообщение от Akupaka При оптимизированом поиске по БД, нет смысла обрабатывать (поиском) все документы БД (например, тыщу), если нужный десяток уже определен (например, еще в первой сотне). А как можно быть уверенным, что "нужный десяток уже в первой сотне"? ;) При оптимизированном поиске или вьюхи правильно отстраиваются или формулы поиска для Search правильно пишутся, чтобы не отбирались лишние документы... 0

@ysovoytobty 0 / 0 / 0 Регистрация: 15.12.2006 Сообщений: 202
	12.07.2010, 15:17	15
	VladSh Не нужно быть столь категоричным. Я вот тоже за несколько лет программирования в Lotus захотел воспользоваться этим параметром лишь в первый раз. Но это еще ни о чем не говорит. На самом деле довольно полезный параметр, когда параметры поиска динамические и заранее не определены (например, вводятся пользователем), а данные нужно отображать в поле (у которого, как известно, лимит в 32кб данных) Безусловно, проблема эта решается циклом и доп.переменными, но дело-то не в этом. Дело в том, что имеющийся функционал не работает так, как должен работать (а уж для чего он может пригодиться - это дело десятое) Akupaka В смысле? Шедульный агент не может обработать больше 10 документов?! Что за ересь? % ))) Или я что-то не так понял? ))) 0

@hosm 0 / 0 / 0 Регистрация: 15.05.2009 Сообщений: 1,454
	12.07.2010, 15:32	16
	может, у него такая сложная обработка и таймаут для агентов. А вообще, плз, поясни, Akupaka, что это было, на базе чего был получен такой опыт. 0

@ныш 0 / 0 / 0 Регистрация: 07.02.2010 Сообщений: 1,063
	12.07.2010, 16:12	17
	Search, вроде бы, создает что-то вроде временного вида с указаной формулой отбора. Так что, в некотором смысле, логично, что параметр не работает - в вид-то первые 10 документов не отберешь 0

@mvyush 0 / 0 / 0 Регистрация: 19.04.2009 Сообщений: 2,219
	12.07.2010, 16:18	18
	Сообщение от Мыш Search, вроде бы, создает что-то вроде временного вида с указаной формулой отбора. Так что, в некотором смысле, логично, что параметр не работает - в вид-то первые 10 документов не отберешь Но серверу не обязательно отдавать все отобранные документы. Пусть возвращает, сколько затребовали. 0

@VtodSh 1 / 1 / 0 Регистрация: 07.12.2009 Сообщений: 1,197
	12.07.2010, 16:35	19
	Сообщение от IsAvailable На самом деле довольно полезный параметр, когда параметры поиска динамические и заранее не определены (например, вводятся пользователем), а данные нужно отображать в поле (у которого, как известно, лимит в 32кб данных) Это разве не задача разработчика правильно сформировать фильтр поиска, т.е. составить формулу, чтобы не отбирать лишнее? Если данных больше, чем 32кб, это разве не задача разработчика правильно разложить данные? Сообщение от IsAvailable Безусловно, проблема эта решается циклом и доп.переменными, но дело-то не в этом. Дело в том, что имеющийся функционал не работает так, как должен работать (а уж для чего он может пригодиться - это дело десятое) Дело в том, что он как раз может не работать из-за того, что не для чего ему пригодиться ))) т.к. атавизм. Сообщение от nvy Но серверу не обязательно отдавать все отобранные документы. Пусть возвращает, сколько затребовали. Т.е. нам фактически до фонаря, какие 10 он возвратит из 10-ти тысяч??? И потом мы будет куда-то записывать или изменять эти данные? Да!... вот это логика приложения... Этот параметр нужен разве что для сайтов знакомств ))) а в бизнес-приложениях, хоть у нас это и довольно гибкая платформа, но, думаю, что всё-таки нужны более весомые параметры, чем "отобрать 10 штук нафонарь". 0

@okupoko 0 / 0 / 0 Регистрация: 04.10.2007 Сообщений: 2,977
	12.07.2010, 17:03	20
	Сообщение от VladSh Что такое "автоматический агент"? Издеваешсо, да? К примеру, шедульный. Вот кто-то пишет шедульный агент по обработке некоторых документов в базе, и пытается его оптимизировать, чтобы он делал не больше, чем может, чем ему нужно за раз. Сообщение от VladSh А как можно быть уверенным, что "нужный десяток уже в первой сотне"? Да нет никакой уверенности. Я говорю для примера. Конечно, десятый док может оказаться последним проверяемым в базе, тогда "оптимизации не вышло" )) Сообщение от VladSh При оптимизированном поиске Влад, ты просил область приминения, я тебе должен был придумать супер сложный пример? )) Сообщение от IsAvailable Что за ересь? Ты что-то не так... Добавлено: Сообщение от OKEN может, у него такая сложная обработка и таймаут для агентов А мне казалось ты меня плохо знаешь Сообщение от Мыш в вид-то первые 10 документов не отберешь Почему же? Реляционные БД с этим справляются на ура, а домино как обычно. Добавлено: Сообщение от nvy Но серверу не обязательно отдавать все отобранные документы Мало того, серверу не обязательно искать ВСЕ документы в базе, чтобы вернуть только 10 затребованных, особенно, если эти десять уже были найдены, например, после проверки лишь 20% всех данных. Влад, есть возражения? ;) Добавлено: Сообщение от VladSh Это разве не задача разработчика правильно сформировать фильтр поиска, т.е. составить формулу, чтобы не отбирать лишнее? Ой-ей... Большинство задач лотусиста сводится к исправлению глюков платформы, "чтоб работало как надо". Добавлено: Сообщение от VladSh Дело в том, что он как раз может не работать из-за того, что не для чего ему пригодиться Тебе нужны страусиные яйца? Мне нет. А вот страусу без них никак... Добавлено: Сообщение от VladSh Т.е. нам фактически до фонаря, какие 10 он возвратит из 10-ти тысяч? ... Этот параметр нужен разве что для сайтов знакомств "Да-да! Я знаю! Меня возьми!" (с) Шрек. Реплика Осла. А я тебе задачу описал, а ты не вник. Давай еще раз - агент не может обработать за запуск более, к примеру, 10 документов. Зачем ему доставать больше? ... А даже, если и так? Лотус на столько крут, что программы типа сайта знакомств не его удел? 0