Большой объем данных в память

Привет, кто что думает по такому вопросу:

Для хранения настроечных данных мы используем лотусовые документы. Далее пишутся классы обертки на эти документы и методы нахождения этих документов по разным критериям через виды. Соотв. схема такая:
1. Нашли документ по критерию
2. Считали инфу
3. Что-то сделали

Документы редактируются редко, но хранят достаточно большой объем инфы.

Что если: программно один раз создать на каждый документ свой экземпляр класса? Соотв мы документы меняем на классы. При инициализации программа создает по одному экземпляру каждого класса и для поиска и чтения информации нам уже не требуются виды, документы и т.д.

Зачем это, возможно, нужно:
1. Настроечные документы фактически являются некими элементами дизайна. Если мы создадим их в видем библиотек, то они будут реально являться экземплярами дизайна. Нужно для контроля версионности, напрмер
2. LN на каждый объект создает C++ реализацию => меньше объектов LN, меньше C++ реализаций
3. В теории поиск по listу в разы быстрее, чем по виду

Недостатки:
1. Непонятно, как будет работать на больших объемах
2. Непонятно, как долго будет все инициализироваться
3. Непонятно сколько памяти будет расходоваться
4. В момент старта необходимо прогрузить все настроечные докуметны в память, хотя потребоваться нам могут лишь часть (думаю, эту проблему можно как-то решить)

0

а как планируеца обеспечивать время жизни объекта( которое предполагается равным времени работы приложения? ) На LS вроде как не получица. Статик java классы, xpages backing beans?
может все-таки на старых добрых профилях?

0

ToxaRat, помнится, предлагал хранить настройки в документе иконки БД. UNID у него для всех баз фиксированный и наперёд известный.

0

turumbay
Мы для этого используем класс Cache:
объявлен как глобальная переменная в библиотеке, доступ через singleton, в него можно пульнуть объект по ключу и получить обратно. Если пульную объект в этот класс, то доступ к нему будет до момента смерти класса cache (если принудительно ничего не чистить).

Здесь такая заморочка:
Есть 200 документов с данными. Из этих 200 документов можно сгенерировать 200 классов (если не больше). При старте программы все 200 классов должны быть созданы и сохранены в кеше. Библиотека с данными классами будет иметь опупенный размер.
Вопросы по такой реализации прежние

0

Сообщение от fedotxxl turumbay Мы для этого используем класс Cache: объявлен как глобальная переменная в библиотеке, доступ через singleton, в него можно пульнуть объект по ключу и получить обратно. Если пульную объект в этот класс, то доступ к нему будет до момента смерти класса cache (если принудительно ничего не чистить).

я туплю, или объект умрет почти моментально??? вьюху переключим и кирдык. документ закрыли - тоже кирдык.
как обеспечивается сохранение состояния этой глобальной переменной? Глобального Declarations для БД вроде еще не придумали?

Сообщение от fedotxxl Здесь такая заморочка: Есть 200 документов с данными. Из этих 200 документов можно сгенерировать 200 классов (если не больше). При старте программы все 200 классов должны быть созданы и сохранены в кеше. Библиотека с данными классами будет иметь опупенный размер.

насколько опупенный? Война и Мир, первый том, из библиотки Машкова весит меньше мегабайта. У вас больше данных?
В конце концов даже пяток метров памяти откушать под цели кэша - никто не заметит.

0

turumbay
Вся логика применима для бэграудных агентов. Для UI врядли такое извращение нужно...

насколько опупенный?

На каждый документ нужно написать отдельный класс. На каждое поле документа нужно написать getter. У нас 500 документов, в каждом 100 полей.

500*(100*3) = 150000 строк кода, сгенерированного автоматически. Мне одному кажется, что это глупая идея?)

0

Сообщение от fedotxxl Мы для этого используем класс Cache: объявлен как глобальная переменная в библиотеке, доступ через singleton, в него можно пульнуть объект по ключу и получить обратно. Если пульную объект в этот класс, то доступ к нему будет до момента смерти класса cache (если принудительно ничего не чистить).

Если это класс ЛС, то идея плохая. Каждый открытый документ, представление, агент, использующие этот класс будут создавать свой экземпляр.

0

nvy
Повторю еще раз - это для большого бэкграудного агента. Пул объектов, чтобы раз создал и используешь в разных формах, стандартным образом создать нельзя... да и речь не об этом

0

Кто мешает получить один раз документ и использовать его везде?

Добавлено: Это я к тому, нафига на каждый документ писать свой класс?
Ну и как объект будет жить тоже до сих пор не понятно. Агент весь день выполняется что ли?

0

fedotxxl
Настроечный документ — на то он и настроечный, чтобы хранить какие-то параметры настройки системы БЕЗ ПРОГРАММИРОВАНИЯ. Впрочем, есть идея от того же ToxaRat — настройки посредством ДХЛ непосредственно внедряются в исполняемый код. Т.е. есть, допустим, у Вас такой код:

, где Param хранится в настроечном документе. При сохранении настроечного документа нужная библиотека выгружается в ДХЛ, в зависимости от значения параметра эти пять строчек кода заменяются на Call SubOne() или Call SubTwo(), затем библиотека загружается обратно. Подробности уточнять у автора идеи, сам я такой подход не пробовал.

0

всё равно не понял зачем всё это :sorry:

0

Сообщение от fedotxxl Пул объектов, чтобы раз создал и используешь в разных формах, стандартным образом создать нельзя...

Ну, не совсем так — есть очереди сообщений. Но они тут вряд ли сгодятся при таких-то объемах.

0

Я тоже ничего не понял

Особенно 500 документов - 500 классов меня добило. Может все таки, 500 экземпляров одного класса?

0

Сообщение от K-Fire Может все таки, 500 экземпляров одного класса?

объектов класса, может?

0

Сообщение от xalet объектов класса, может?

это одно и тоже.

0

Сообщение от fedotxxl nvy Повторю еще раз - это для большого бэкграудного агента. Пул объектов, чтобы раз создал и используешь в разных формах, стандартным образом создать нельзя... да и речь не об этом

не понятно, о чем же все-таки речь - бекграундный агент.. а потом формы какие-то ?

0