Getallentrysbykey

[dimat]

Всем привет.
Получаю коллекцию документов NotesEntryCollection с помощью:

Set EntryCollection=NotesView.GetAllEntriesByKey("AnyKey")

В представлении около 38 тыс. документов, скажите такое время выполнения нормально?
В чем может быть проблема или как оптимизировать?

 

[allex]

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

 

[lionk]

попробуй выбрать через

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

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

 

[lmike]

lionk
не будет быстрей, да ещё и память угрохает...

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

 

[Omh]

Ты выбираешь по ключу?
Или тебе все доки из view нужны?

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

 

[lionk]

не будет быстрей, да ещё и память угрохает..

а можно по подробнее, что именно память угорхает?

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

 

[dimat]

Мне нужно по ключу взять первые 2 Entrys/Documents так же как они расположены в виде, вот как то бы сделать это быстрее 1 минуты

 

[Medevic]

Здесь написано.
link removed

 

[nnikishi]

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

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

 

[rinsk]

Можно еще и такое чтиво:

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

 

[lmike]

всё время пользуюсь notesView.GetAllDocumentsByKey

коллекция кэшируется (сами доки) на клиенте, если доков много - будет оверхед по памяти, да ещё и по трафику

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

 

[lionk]

коллекция кэшируется (сами доки) на клиенте, если доков много - будет оверхед по памяти, да ещё и по трафику

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

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

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

 

[lmike]

А если нужно изменить колекцию документов и посохранять их кто оптимальние?

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

 

[nnikishi]

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

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

 

[lmike]

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

вам не кажется это утверждение противоричивым :YES:?
узкий канал - тормозов нет
док кэширутся - а остальные (некий буфер) - нет

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

 

[nnikishi]

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

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

 

[lmike]

какие вы отличия получите? данные будут идентичны.

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

 

[TIA]

коллекция кэшируется (сами доки) на клиенте, если доков много - будет оверхед по памяти, да ещё и по трафику

Не, реально сами доки всей коллекции не кешируются на клиенте. На клиент передаётся список NoteId.
Coll.getNextDocument открывает по очередному NoteId документ с сервера. Как только скриптовых ссылок на документ не остаётся, хэндл ноты закрывается и связанная с хэндлом память очищается. Так что, если дополнительно не хранить полученные открытые документы в других структурах, типа List, оверхед по причине большой коллекции будет мал.

 

[lmike]

Не, реально сами доки всей коллекции не кешируются на клиенте. На клиент передаётся список NoteId.

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

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