Getallentrysbykey

dimat

Lotus team
31.07.2008
516
0
#1
Всем привет.
Получаю коллекцию документов NotesEntryCollection с помощью:
Код:
Set EntryCollection=NotesView.GetAllEntriesByKey("AnyKey")
В представлении около 38 тыс. документов, скажите такое время выполнения нормально?
В чем может быть проблема или как оптимизировать?
 
A

allex

#2
А вы все 38к разом выбираете и что оптимизировать (что вас не устраивает ?)
 

lionk

Well-known member
05.04.2007
310
2
#3
попробуй выбрать через

Set notesDocumentCollection = notesView.GetAllDocumentsByKey( keyArray [, exactMatch% ] )
или через
Set notesViewNavigator = notesView.CreateViewNavFromCategory( category$ [ , cacheSize& ] )

сравни может будет быстрее
 

lmike

нет, пердело совершенство
Lotus team
27.08.2008
6 600
277
#4
lionk
не будет быстрей, да ещё и память угрохает...

а чем не устраивает получать первый этнрис по ключу, а потом - бежать по вьюНавигатору (конвертнув энтрис)
 

Omh

Lotus team
04.07.2007
2 210
1
#5
Ты выбираешь по ключу?
Или тебе все доки из view нужны?

И попробуй поставь вторым параметром True.
 

lionk

Well-known member
05.04.2007
310
2
#6
не будет быстрей, да ещё и память угрохает..
а можно по подробнее, что именно память угорхает?

всё время пользуюсь notesView.GetAllDocumentsByKey, если нужна выборка без учёта положения в виде.
Нариканий не замечал.
 

dimat

Lotus team
31.07.2008
516
0
#7
Мне нужно по ключу взять первые 2 Entrys/Documents так же как они расположены в виде, вот как то бы сделать это быстрее 1 минуты
 
N

nnikishi

#9
NotesView.AutoUpdate = False стоит перед getallentriesbykey?

Для восьмерки вроде как очень даже критично стало...
 

lmike

нет, пердело совершенство
Lotus team
27.08.2008
6 600
277
#11
всё время пользуюсь notesView.GetAllDocumentsByKey
коллекция кэшируется (сами доки) на клиенте, если доков много - будет оверхед по памяти, да ещё и по трафику

при ентрисах - обращение идёт в индексу вьюшки (если не получать док из энтриса)
 

lionk

Well-known member
05.04.2007
310
2
#12
коллекция кэшируется (сами доки) на клиенте, если доков много - будет оверхед по памяти, да ещё и по трафику

при ентрисах - обращение идёт в индексу вьюшки (если не получать док из энтриса)
ну это понятно что если нужно только получить инфу с дока то выгодно использовать viewentry и колум валуе, это самое бысторе.
А если нужно изменить колекцию документов и посохранять их кто оптимальние? :
Set EntryCollection=NotesView.GetAllEntriesByKey("AnyKey")
Set notesDocumentCollection = notesView.GetAllDocumentsByKey( keyArray [, exactMatch% ] )
Set notesViewNavigator = notesView.CreateViewNavFromCategory( category$ [ , cacheSize& ] )

(ФТ поиск по базе опускаем)
 

lmike

нет, пердело совершенство
Lotus team
27.08.2008
6 600
277
#13
А если нужно изменить колекцию документов и посохранять их кто оптимальние?
опятьже - зависит от задачи...
но док получать - полюбасу "тащить с сервера", а уж как - это вопрос открытый...
большую колекцию доков вываливать ради анализа - нет смысла
а отдельные - можно и по ЮНИДу таскать (дайжестсёрч так работает)
 
N

nnikishi

#14
откуда информация что коллекция кешируется?
работал через узкий канал, брал всяческие коллекции, никаких тормозов нет, не переполнялось ничего ни разу, а вот док кешируется это правда

был даже случай экстрактил отчет в эксел с Лотуса, тяжелая коллекция, более 40 тыщ доков, и в каждом доке куча полей. Так вот, по причине провайдера канал отваливался несколько раз на чуть-чуть (а он и так узкий), но Лотус держался, агент работал. Только в экселе потом обнаружил кучу пустых строк. Ошибок агент не дал. Т.е. он брал документ и когда канал падал, не мог подтянуть поля. Ну и какое кеширование коллекции?
 

lmike

нет, пердело совершенство
Lotus team
27.08.2008
6 600
277
#15
работал через узкий канал, брал всяческие коллекции, никаких тормозов нет, не переполнялось ничего ни разу, а вот док кешируется это правда
вам не кажется это утверждение противоричивым :YES:?
узкий канал - тормозов нет
док кэширутся - а остальные (некий буфер) - нет ;)

поясните мне (тогда) почему: когда я сделаю DbSearch и побегу по колекции - я получу отличия в разы от ситуации, когда я побегу по энтрисам и буду получать док из энтриса?
 
N

nnikishi

#16
где противоричия? я подразумеваю под кешем запись на локальный диск в базы cache.ndk, desktop6.ndk и bookmark.nsf:
коллекция не кешируется вообще
док кешируется и то минимально, если он конечно не профильный

какие вы отличия получите? данные будут идентичны. Скорость по ентрисам будет чуток быстрее, потому что вы идете по уже построенному индексу. И то, вопрос перфоманса достаточно спорный, если вы только не забираете данные из ColumnValues
 

lmike

нет, пердело совершенство
Lotus team
27.08.2008
6 600
277
#17
какие вы отличия получите? данные будут идентичны.
прочитайте внимательно и потестируйте ;) я не буду ничего доказывать - не вижу смысла - если вы даже не удосужились проверить
 

TIA

:-)
Lotus team
15.05.2009
790
3
#18
коллекция кэшируется (сами доки) на клиенте, если доков много - будет оверхед по памяти, да ещё и по трафику
Не, реально сами доки всей коллекции не кешируются на клиенте. На клиент передаётся список NoteId.
Coll.getNextDocument открывает по очередному NoteId документ с сервера. Как только скриптовых ссылок на документ не остаётся, хэндл ноты закрывается и связанная с хэндлом память очищается. Так что, если дополнительно не хранить полученные открытые документы в других структурах, типа List, оверхед по причине большой коллекции будет мал.
 

lmike

нет, пердело совершенство
Lotus team
27.08.2008
6 600
277
#19
Не, реально сами доки всей коллекции не кешируются на клиенте. На клиент передаётся список NoteId.
наверняка оно так (тут я соврамши)
Но вопрос - зачем тогда получать эту коллекцию...
проанализировать данные полей можно и просто - бегая по энтрисам и колумнвэлью
на колекциях измеряемых тыщами - будет всё-таки, кмк, заметно (потребление памяти)

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