https://tixomir.wordpress.com/2015/02/02/live-view-refresh-in-domino-9-0-1fp3/
Наткнулся на это. Есть ли у кого доп информация по реализации этой фичи ? Пробовал запустить - пока никакой реакции не увидел. Может ему какой-ть параметр в .ини нужен...

 

интересно, не сталкивался

 

Вот тут - http://www.xpagedeveloper.com/2015/news-from-ibm-connected15
еще интересные картинки. Суди по всему нас ждет разделение индексов и скоро.
Что то не могу найти нигде саму презентацию...

 

оч интересно...
оно всетаки как то работает)))

 

На сколько я понял, оно позволяет отдать "грязные" данные клиенту по аналогии с SQL версионингом...
Только реализация, мягко говоря через одно место... а если у меня таких вьюшек 100?

 

Кто о чем...
Эта штука прописывает во вьюшки в поле $Index значение "/U=D/R=0", обычные содержат "" или ""/O".
Из ком строки не убивается. При пересохранении из дизайнера вью становится обычной но надо restart task update.
При старте сервера Update Task находит эти вьюшки и цепляется к ним - но что то загрузка там под 100%...

 

начало было интригующим, но видать не допилили...

View Indexes outside of the database and with this and DAOS we are breaking the 64GB nsf database maximum finally.

вот это уже возбудило придало веру в будущее
[DOUBLEPOST=1426083477,1426083264][/DOUBLEPOST]

New backend classes for XPages, Lotuscript and Java agents
There are plans for future upgrades to update java in Domino to 1.7 or 1.8

даешь версию домино10 с азартом и веселыми дамами...
а стал картинки смореть из ссылки

 

>вот это уже возбудило придало веру в будущее
да уж, вера, на то она и вера
link removed

 

>вот это уже возбудило придало веру в будущее
да уж, вера, на то она и вера
link removed

нутак - сделали же
по ИБМ-омски - очень оперативно (менее 10-ти лет)

 

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

 

Случайно нашел ( последний пост link removed )
Separating out the view indexes is only available in the upcoming R9.0.2 release.

А R9.0.2 в этом году - не видать ( http://www-10.lotus.com/ldd/fixlist.nsf/(Progress)/$First?OpenDocument )

 

Ну и забудем, до поры.
... А помнить будем

 

такими темпами база скоро вся будет в виде отдельных файликов - и да здравствует снова новел?

 

Novell тут не при чем. Есть ограничение в 64 Гб.
За десяток лет произошла консолидация многих баз, до этого бывших территориально-разненсенными.
64 Гб стало мало. Первым пришел DAOS, и это была бомба.
Теперь ждем индексы видов, вынесенные за NSF.
Обе меры никак не отменяют потребность в увеличении текущего лимита в 64 Гб.

 

Обе меры никак не отменяют потребность в увеличении текущего лимита в 64 Гб.

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

 

рабочие базы не превышают этот лимит)

Можно сказать что везет
Мне как то все приходится с мильонами в базах мучится. Иногда индексы превышают 70% размера базы...
Надеюсь каждый индекс они сделают в виде отдельного файла.
Необходимость изменений в структуре базы назрели еще давно - лет 10 назад. Но тогда пришло шибко умное руководство в IBM - причем из Майкрософт и сказало - марш все в вебсферу. Потом под градом критики как то все умолкло. Потом выкатили идею nsf2db2. которая так же благополучно померла. Было потеряно время. Но сам IBM не сопротивлялся этой диверсии ибо были в кейсе и апликейшен решения и решения по DBMS коим обновленная LND составила бы конкуренцию. А вот в messaging альтернативы нет -родили DAOS, чтоб не разбежались. Выкатив платформу xPage - (а иначе оно бы померло) - опять таки уперлись в подсистему хранения ибо сам по себе ява стек обладает достаточным для большинства применений потенциалом, а вот бакэнд подкачал. Приходится зеркалить nsf на сиквел.
Можно было бы давно родить что то подобное MongoDB\couchdb в домино если бы...
короче это только бизнес - ничего личного))

 

Можно было бы давно родить что то подобное MongoDB\couchdb

эти проекты открытые - даже рожать ничего не надо - просто позвать Каца
[DOUBLEPOST=1427357132,1427357067][/DOUBLEPOST]

Приходится зеркалить nsf на сиквел.

подобным идиотизмом МС славится (в своей чанге) - они еще этим и гордятся

 

мне одному кажется что ограничение в 64 гига существует лишь для тех БД, которые не поддерживаются и в тех. поддержке не учавствуют?

из разряда вот вам система - работайте в ней, поддержка ей не нужна, и через 10 лет "КАРАУЛ, ПЕРЕПОЛНИЛАСЬ"

 

совершенно верно - одному

 

А если не секрет, то чем вы забиваете 64Гб. Это прямо оперативная база из одних документов?
Тут я ToxaRat согласен. Всегда можно что-то допилить или изменить туже бизнес логику с созданием архивов.
У нас например тоже была в прошлому база канцелярии под 64Гб - забили сканами документов.
Коллега, расковырял возможность подменить через dxl+java картинку с аттачментом на ссылку на это тот же файл, но уже на веб-сервере, в виде этой же картинки.
Фактически сделали аналог DAOS, но сразу для двух серверов в кластере, да ещё и с дедупликацией. В итоге в оперативных документах приложения в виде аттачментов, а в списанных в дело они выносятся из базы.