64k - сумма всех summary в доке и одновременно не более 32k для каждого поле summary
Тогда я тоже чот не понимаю
"Регистрирую следующий контакт"(с), "...нахожу историю из тех же ста контактов + предыдущий с письмом"(с) - значит "следующий контакт" - ответ на предыдущий. Так?
Значит стандартная иерархия.
Значит для юзанья xpages (в браузере, можно эмбедднутом на форму или в Ж-фрейме) достаточно nhttp.exe c сопутствующими DLL и конфигом, запускать его превентивно (nhttp.exe preview на открытии базы, если уже запущен ничего страшного - будет просто игнор) и можно юзать. Правда, как в терминале будет фунциклировать не знаю.
Многие ко многим с xpage и даже с нативным клиентом можно делать с третьей - прокси базой. архитектура которой зависит от взаимосвязей событий. т.е. первичный ключ - ид клиента. вторичный - ид событий. все ключи - многозначные. в пределе кол- во записей == кол во клиентов. в 32к можно дофига ид событий уложить. и основные доки не модифицируются. это кста и с обычным sql практикуют
+ upd
и да - обещают скоро 16 мег суммари полей )
+ upd
и да - обещают скоро 16 мег суммари полей )
Последнее редактирование модератором:
Нет, все контакты только входящие, никаких ответов нет. Никакой иерархии. Поясняю. Большое кол-во клиентов проявляют сильное нетерпение и шлют запросы по одной и той же теме каждый день. Понятно, что на подготовку ответа нужно какое-то время. Т.к. обработкой запросов могут заниматься разные сотрудники, они будут готовить один и тот же ответ одновременно. В результате по одному вопросу, по десяти запросам будет подготовлено десять ответов. При такой работе эффективность этой службы ниже плинтуса. Одна и та же работа дублируется разными сотрудниками по несколько раз. Следовательно, при получении запроса, сотрудник, занимающийся его обработкой, должен понимать - это уникальный запрос или "дубль", соответственно, принять решение - нужно ли подготовить ответ на этот запрос или подготовить один обобщающий ответ сразу на несколько "дублей". Либо "скинуть" данный запрос сразу в архив, т.к. уже ведётся работа по подготовке ответа по аналогичному предыдущему запросу либо ответ уже был дан, например вчера. Из таблички "история" он видит состояние предыдущих запросов.Тогда я тоже чот не понимаю
"Регистрирую следующий контакт"(с), "...нахожу историю из тех же ста контактов + предыдущий с письмом"(с) - значит "следующий контакт" - ответ на предыдущий. Так?
З.Ы. База очень большая, с очень богатым функционалом, всё сделано в классическом клиенте Lotus Notes, что-либо переделывать в этой базе под XPage не вариант.
Памяти много жрет клиент полный, поэтому и basic, календари не глючат и поддержка JavaUI отсутствует.
Так.. есть вариант, с вьюхой, но весьма поганый.
Делаем базу, да, еще одну базу.
В ней документы-ссылки.
В документ пишем: UNID-ы контактов, UNID -запроса, путь к базе где лежит запрос, тему запрос.
Один запрос - одна ссылка.
При открытии такой ссылки открывать запрос.
Да, документов в базе будет много, но они мелкие и меняться сильно не будут, только добавляться новые.
Архивы запросов можно так и оставлять в разных базах, путь к базе мы же прописали в ссылку.
Можно делать такую базу на букву алфавита, первая буква фамили контакта, тогда количество документов уменьшится, но будет больше отдельных баз. Тогда еще в сам документ контакта надо будет прописывать документ базы с ссылками на запросы (или механизм определения базы создавать)
Ну и при архивировании запросов надо будет все ссылки пересчитывать.
Проблема с одним запросом на разных клиентов решается созданием еще одной ссылки, но уже для другого контакта.
Идея ясна или слишком сумбурно описал?
Опять двадцать пять.
1 Если документ (обработка запроса) предполагает реакцию на предыдущие аналогичные документы, значит иерархия есть (в простейшем случае - временная).
2 Всё таки ведётся обработка актуальных запросов, а они в ОДНОЙ рабочей базе. Архив, кагбэ, побоку - для оперативной работы он не актуален. Значит для контроля "истории"достаточно обычной работы с вью текущей базы.
3 Каким образом сотрудник выходит на нужный список "истории запросов"? Ведь это не одна глобальная таблица. Исходя из контекста?
Тогда напрашивается следующий механизм:
По контексту запроса, автоматом, во время ввода инфы, (см. LiveSearch напр. или что-то похожее) отбираются доки (в оперативной базе и, может быть в архиве, для контроля. Отдельно) и показываются в 2 фолдерах в иерархии респонзов.
Каждый новый сохранённый запрос является родителем (если он самый первый) или делается респонзом к родителю или любому записанному запросу в самой нижней ступени иерархии найденных и связанных по смыслу доков.
Если так интересно, расскажу как показать в обычной вьюшке (фолдере) доки в иерархии "ответ\ответ-на-ответ", БЕЗ парента, для реализации предложенного.
Щас придет лесник ToxaRat и покрошит в капусту эти архитектурные выверты ))))
К сожалению, списка рефов АКА один ко многим в рамках одной вьюшки нет(
Примерно такая же проблема как и у автора темы, есть древнейшая база, с огромным количеством полей. И вот среди них нашлись 3 summary=true поля, в которых хранится инфа следующего типа: SummaryField1 - порядковый номер, SummraryField2 - текст (объемная инфа хранится), SummaryField3 - дата добавления. И все это еще отображается в поле с настройкой ComputedForDisplay. Есть функционал которые в эти поля добавляет/редактирует/удаляет инфу. Все было хорошо, пока поле SummaryField2 не переполнилось. Думаю над решением. Хотел добавить ритч текст поле, но тут проблемка, как программно туда смигрировать значения из этих полей чтобы визуально это было видно? Делаю что то типо такого:
Прошу не обращать внимание на название полей и что записываю только 0 элемент из поля. Как я понял, ритч текст не обновляется пока документ открыт. Вот как сделать, чтобы пользователь нажал на кнопку, и инфа оказалась в этом поле не переоткрывая документ?
Код:
On Error Goto eh
Dim ws As New NotesUIWorkspace
Dim richTextItem As NotesRichTextItem
Set richTextItem = ws.CurrentDocument.Document.GetFirstItem("Resol")
If richTextItem Is Nothing Then
Set richTextItem = ws.CurrentDocument.Document.CreateRichTextItem("Resol")
End If
Call richTextItem.AppendText(ws.CurrentDocument.Document.Summary1(0) + " - " + ws.CurrentDocument.Document.Summary2(0))
Call richTextItem.Update()
Goto ex
eh:
Msgbox Error & " on line " & Erl
Resume ex
ex:а зачем именно в UI мигрировать?
В бакэнде или в крайнем случае на QueryOpen формы.
Если SummaryFieldNN - NN немного, то можно все слить в РТ таблицу из 3-х колонок...
И программно можно будет обращатся к данным, соотв образом модифицировав функционал.
Добрый день.
Столкнулся с похожей проблемой: сумма summary полей вылезает за 64к. База древняя, классический веб. У 99% полей стоит флаг "Is Summary". Что-то не догоняю, как его снять правильно...
Вообще где он первоначально выставляется по дефолту? В свойствах поля в дизайнере не нашел такой галки.
Как его теперь правильно снять для всех доков сразу? Только программно, т.е. перебрать все и принудительно конкретному Item'у выставить Issummary = False и сохранить док? Честно говоря, не хотелось, т.к. доков таких под пол мульта.
Столкнулся с похожей проблемой: сумма summary полей вылезает за 64к. База древняя, классический веб. У 99% полей стоит флаг "Is Summary". Что-то не догоняю, как его снять правильно...
Вообще где он первоначально выставляется по дефолту? В свойствах поля в дизайнере не нашел такой галки.
Как его теперь правильно снять для всех доков сразу? Только программно, т.е. перебрать все и принудительно конкретному Item'у выставить Issummary = False и сохранить док? Честно говоря, не хотелось, т.к. доков таких под пол мульта.
проблема пока не решена архитектурно.
в следующих версиях обещают увеличить максимально допустимый размер, но когда и как это будет, вопрос?
я сомневаюсь, что у вас много таких документов. агент для проверки и правки - самое очевидное решение.
в следующих версиях обещают увеличить максимально допустимый размер, но когда и как это будет, вопрос?
я сомневаюсь, что у вас много таких документов. агент для проверки и правки - самое очевидное решение.
Последнее редактирование:
Неизвестно сколько таких представлений, где оно может использоваться. В базе помойка, до которой только сейчас руки дошли. Вообще с ошибкой столкнулся первоначально через утилиту scanEZ и только благодаря ей удалось локализовать проблему.
тогда у вас реальная проблема, но в любом раскладе - 32к в колонках вьюшки, "да за такое убивать надо"
погорячился я с полмульта... почти полтора мульта доков и под 40 гигов веса. Одних индексов гигов 10 наверное.да, полмульта - фигня
Абсолютно согласен, но что имеем, то имеем, так сказать. Т.е. все таки без массового апдейта доков и ревизии вьюшек никак?
И все таки, все поля по-умолчанию summary, или это как-то рулится?
да, никак не рулится, и КМК еще и при comouteWithForm вернет обратно
вернее рулится - если создавать изначально вне формы (а на форме таких не создавать)
еще нет у РТ этого флага
Похожие темы
- Закрыто