Мы при построении таблиц с большим кол-вом строк не используем addRow (как раз из-за медленной работы метода начиная с определенной строки), а Call RTItem.AppendTable(255, ...) и до построения получаем размерность таблицы.
-
15 апреля стартует «Курс «SQL-injection Master» ©» от команды The Codeby
За 3 месяца вы пройдете путь от начальных навыков работы с SQL-запросами к базам данных до продвинутых техник. Научитесь находить уязвимости связанные с базами данных, и внедрять произвольный SQL-код в уязвимые приложения.
На последнюю неделю приходится экзамен, где нужно будет показать свои навыки, взломав ряд уязвимых учебных сайтов, и добыть флаги. Успешно сдавшие экзамен получат сертификат.
Запись на курс до 25 апреля. Получить промодоступ ...
Тут, очевидно, заранее необходимо знать конечное количество строк в таблице/таблицах. А как осуществлять навигацию по таблице, если их несколько в RTF поле, для заполнения ячеек данными? Например, я беру последнюю таблицу в поле, добавляю в неё строку и заполняю её значениями. Как "выйти" на нужную строку, например 300-ю?
Не использовать РТ-таблицы. Для работы\динамического изменения\удобной навигации в форме: плоские таблицы - вьюшки, сложные - хэпаги\хтмл.
Поясните, пожалуйста, что есть "плоские таблицы"? Сразу оговорюсь - наличие "лишних" пары миллионов документов в базе "очень" нежелательно, если речь идёт об embedded view.
без вкладок, категорий, без объединения ячеек и т.д.
Если верно понял.
Я вынес у себя в отельную базу и теперь ИС состоит из двух баз.
Верно.
Типа база отчётов. Класно, когда надо возвращаться к ранее созданному.
Почему? Если речь идёт о быстродействии, то показ громоздкой РТ-таблицы на порядок медленнее, чем показ вьюшки с таким же наполнением инфой. Более того, эти доки-строки не обязательно "привязывать" в вьюшке (если есть боязнь тормозов с индексами) - их можно динамически отбирать в коллекцию, по надобности, и класть в фолдер (только не по одному, а все сразу PutAll...)
Есть база с контактами с клиентами, типа "позвонил", "письмо прислал", "сам пришел" и т.п. что-то типа CRM. Соответственно, каждый такой контакт в дальнейшем соответствующим образом обрабатывается специально обученными людьми. Т.к документов в базе быстро собирается огромное количество, чтобы как-то утихомирить бесконечный процесс индексации вьюх на сервере, базу порезали на "архивы" по годам. В каждом таком архиве в среднем полтора-два миллиона документов. Теперь поступила новая вводная: при создании нового контакта с клиентом "подтягивать" и как-то отображать историю предыдущих. Показать в embedded view документы из разных баз не получится. Собрать для этого их обратно все в одну, а нафига мы её тогда на архивы резали? К тому же, надо учитывать, что один "архивный" документ может быть "историей" для нескольких новых контактов. Т.е. получается связь многие-ко-многим. Есть какие-нибудь идеи?
Если подойдет отображение в диалоге, то идеи есть.
Если вкратце... получаете доки из нескольких баз, копируете их в локальную базу(например кэш) , из нужно базы копируете в локальную вьюху(папку), в диалоге отображаете данные документы из локальной базы по вьюхе из этой базы.
Идея помойму с интертраста. Даже какие-то реализации были.. найти сейчас не могу
P.S. После окончания работы все за собой чистить
После создания контакта сохраняем его в "истории" - дереве контактов\зависимых доков-ответов.
История - JSON список напр. с номером контакта\UNID самого дока-контакта\UNID родителя\где лежит (сервер\база\реплика ...) он и родитель.
Списки строятся от каждого Адама отдельно.
Они даже могут пересекаться, что можно красиво показать.
Храним где удобно в тексте или эртээфе, да хоть в отдельном файле.
Чтение "истории" - хэпажная вьюшка куда дёргается инфа из этого списка и показывается деревом (вся или от любого родителя вниз). Где сами доки лежат, значения не имеет - инфу дёрнешь, был бы доступ к серверу\базе\архиву.
Если кому-то что-то не положено - док будет просто пропущен в вьюшке и, возможно, будет потеряна часть реального дерева.
Сопсно - это механизм категоризированного view, только без ограничения принадлежности доков одной базе.
Можно даже не следить за удалением доков - нету дока по такому юниду в списке ну и хрен с ним, просто оборвётся цепочка показа ветки.
Кста, можно даже не хранить "историю" отдельно - достаточно в каждом доке хранить UNID родителя (родителей) и его место нахождения. Хепажная вьюшка будет тогда строиться дольше, зато дерево можно строить не только сверху-вниз но и вверх тормашками
В реале, чтение 10 000 доков - не больше 1 сек. конечно если инфу из их не показывать сразу всю на страничке и эт при чтении из той же базы.
В реале, чтение 10 000 доков - не больше 1 сек. конечно если инфу из их не показывать сразу всю на страничке и эт при чтении из той же базы.
Увы не подойдёт. Создание таблицы "истории" происходит в оффлайн режиме. Есть люди, кот. просто не задумываясь заводят новые контакты, а есть специально обученные, которые принимают решения что с этим контактом в дальнейшем делать, как обрабатывать. В момент "перехода" от пользователя, кот. завёл контакт, к пользователю, кот. принимает решение эта табличка и должна быть заполнена. И на основании этой "истории" в частности и принимается решение. Время заполнения таблицы не предсказуемо, пользователей задерживать нельзя, а если второй получит в работу документ на 5 минут позднее, то ничего страшного. Пока вижу технически работающее, но "не кошерное" решение - записывать HTML текст в RTF поле, затем показывать его во внешнем браузере. Хотелось бы видеть таблицу прямо на форме, "без посредников". Работает всё это в классическом клиенте, никакого web, никаких XPages.
[DOUBLEPOST=1435582169,1435581873][/DOUBLEPOST]
Это означает постоянное обновление/сохранение документов и обновление представлений. Сервак только этим и будет заниматься, а у нас на него ещё и другие планы имеются.
[DOUBLEPOST=1435582310][/DOUBLEPOST]
Устраивает. Как показать более 32К?
На Page в отдельном фрейме? Можно подумать об этом. А как хранить данные для отображения? Не вычислять же их перед каждым открытием документа.
Ничуть не разу. Инфа о родителе пишется ТОЛЬКО 1 раз при создании. При построении хепажной вьюшки - бегаешь по всем связанным юнидами докам и динамически строишь дерево для показа. Яж говорю, механиз такой же, как показ иерархии в классике, только опора не на индекс вида, а на реальную инфу (юнид родителя-потомка) в доках.
[DOUBLEPOST=1435583216,1435582982][/DOUBLEPOST]
Вычислять. Всё равно показывать всю историю напр. из 1000 уровней не comm il faut, а сотня-другая вычислится мухой.
Отчего же? Регистрирую новый контакт - клиент прислал письмо, при этом нахожу историю из ста предыдущих контактов. Сохранил... Регистрирую следующий контакт - клиент позвонил по телефону: "А как там моё письмо?", нахожу историю из тех же ста контактов + предыдущий с письмом. Куда какую инфу надо записать один раз чтобы сохранить все эти связи?
З.Ы. и никаких "хепажных вьюшек" (это же XPage?), я уже говорил ранее только классический клиент.
вычислять-вычислять. сейчас же вы строите таблицу на основании каких-то вычисляемых данных? вот и в явовскую таблицу пихайте их же. с учетом потоков ui не подвиснет, а секунду-другую пользователь подождет.
причем апплет можно сразу не показывать, а спрятать в эмбэданутый едитор за закладку, чтобы не грузился при каждом открытии формы (ну, или в отдельный фрэйм спрятать, как вы пишите).
И записал в новый контакт юнид дока на который создан ответ (или сделал его респонсом, что одно и тоже)
У клиентов Basic? Тогда лицензионный облом-с (
Тут как бы всё наоборот. Этот новый контакт должен уметь показать "историю" предыдущих контактов. Как бы он главный, а они респонзы. Причём каждый из этих респонзов может иметь много главных. Я же говорил многие-ко-многим. Или я чего-то не понимаю?
С лицензиями у нас вроде всё в порядке, но почему-то наши сисадмины хронически не любят стандартного клиента. Понаставили всем Basic. Очень много пользователей из филиалов подключаются через терминал и в нём у них какая-то проблема с эклипсовым клиентом.
Обучение наступательной кибербезопасности в игровой форме. Начать игру!