Eloquera II

краткое описание / немного истории / установка / режимы работы базы: service, inmemory, desktop / восстановление базы
конфигурация / программная конфигурация / простейшие операции CRUD / insert / update / refreshMode / delete

Конфигурация

Файл конфигурации в поставке для автономной работы (Desktop mode) по умолчанию выглядит следующим образом:

 

Прошу обратить внимание на то, что путь для баз данных не указан. Для корректной работы надо будет его дописать, используя атрибут DatabasePath в узел Server.

Внимание!

С версии 4.0 можно полностью игнорировать файл настройки и задание директории для хранения баз данных. Eloquera самостоятельно все определит и настроит.

В узле Server возможны следующие атрибуты:

  • ServerPort – позволяет указать порт на котором будет подниматься сервис EloqueraDB. Есть возможность установить несколько экземпляров Eloquera и разнести их по разным портам. Значение по умолчанию 43962.
  • DatabasePath – путь до места, где будут храниться базы данных. Традиционно рекомендуется указывать путь не на системном диске. По умолчанию будет создаваться путь до места установки сервиса Eloquera.
  • IpAddress – явное указание атрибута заставит сервис принимать соединения только с указанных адресов. Удаление атрибута, либо выставление в качестве значения пустой строки позволит сервису принимать соединения со всех адресов.
  • Secure – указывает на необходимость аутентификации при соединении с сервисом и шифрования трафика между сервером и клиентом. В конфигурации по-умолчанию не используется.
  • AllowUsers – параметр может содержать список пользователей разделенных «;», которым разрешен доступ к текущей базе. Имена должны задаваться в формате «Domain\UserName». По умолчанию строка пуста.
  • AllowGroups – указывает каким группам пользователей разрешен доступ к текущей базе. Группы так же должны быть разделены «;». По умолчанию выставлена группа Everyone.
  • InMemoryAllowed – разрешает (true) или запрещает (false) использование базы в режиме размещения только в оперативной памяти.
  • WriteThru – если база данных работает в нестабильном окружении рекомендуется включить (true) эту опцию.
  • MemoryFootPrint – значение меньше или равное 100 будет интерпретировано как процент памяти доступный для кэширования данных. Значение более 100 будет понято как размер памяти в килобайтах доступный для кэша.
Внимание!

Не рекомендуется использовать MS Word или похожие текстовые процессоры для редактирования файла конфигурации

Все изменения будут приняты только после перезапуска сервера EloqueraDB.

Программная конфигурация

В последних версиях (с версии 3.1.2) возможно программное задание настроек сервера. Для этого нужно использовать класс DB и его статические свойства.

Вот так, например, можно задать путь для хранения баз данных:

Все остальные значения параметров из файла конфигурации можно так же задать с помощью DB.Configuration.

Внимание!

Несмотря на то, что вы задаете путь до директории к базам, обращаясь к статическим полям класса BD, необходимо сначала создать экземпляр класса.

Программная конфигурация работает только для режима встроенной базы.

Простейшие операции CRUD

Для этого раздела в качестве подопытного объекта будет некоторое время выступать такой класс:

Т.е. подопытный класс содержит приватные поля только для чтения, поля, свойства. Никаких специальных атрибутов к классу не применяется.

Далее рассмотрим основные операции для вставки, обновления и удаления записей.

Insert

Запись в базу данных осуществляется вызовом метода Store у движка базы.

Всё. В этот момент в базе зарегистрировался новый тип данных. Класс, переданный на сохранение, неявно получил уникальный номер в базе. Переданный объект сохранился в базе.

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

Проверить можно с помощью теста (тест проходит, так как переопределен метод сравнения для SimpleClass):

Вообще, Eloquera может сохранять объекты любой сложности.

Следующий вопрос, который закономерно возникает: «Как делать пакетную вставку данных?». Так же как и обычную, надо только передавать на сохранение коллекцию объектов.

Т.е. :

В savedItems будут находиться 3 элемента класса SimpleClass. Именно те, которые были сохранены.

Update

Для обновления ранее сохраненных данных, в общем случае их надо просто заново сохранить с помощью того же метода Store(). Т.е. если объект будет найден в базе, то он обновится, если нет – то добавится.

В данном моменте хочу заметить, что такое обновление сработает, только если соединение с базой не было закрыто между получением объекта и его сохранением.

Для того чтобы обновление осуществлялось при работе с  клиент-серверными приложениями (в режиме, когда отсоединятся от базы понадобится в любом случае) надо использовать атрибут ID.

Каждый объект, сохраняемый в базу данных, получает свой уникальный номер (UID), по которому можно получить к нему доступ. Начиная с версии 3.1, движок базы может в автоматическом режиме записывать значение UID в поле класса отмеченное атрибутом ID. Так как в самой базе UID имеет тип long, то назначение атрибута ID на поля отличные от типа long, к примеру, на тип string, ничего не даст. И еще раз для закрепления материала: атрибут может быть применен только к полям класса.

 

Внимание!

Никогда не назначайте в ручную UID, это ответственность базы и она полностью контролирует этот процесс. Назначение UID сложный процесс и даже в только что созданной базе, когда вы сохраните единственный объект, его номер не будет равен 1.

Пример корректного обновления объекта при закрытии базы:

Ключевые моменты для работы в распределенном режиме:

  • RefreshMode – необходимо выставить в AlwaysReturnUpdatedValues, для того, чтобы запросы возвращали данные которые были обновлены в текущей сессии.
  • Запрос объекта из базы – вернет объект с обновленным полем, которое было помечено атрибутом ID.
  • Использование перегруженного метода Store с указанием ID объекта, который надо обновить.

RefreshMode

Объекты на клиенте существуют независимо от серверной части и могут редактироваться одновременно во многих клиентских приложениях независимо. После записи данных в БД возникает несоответствие между слепками объекта в базе и на клиентах, которые не знают об обновлениях. Эта проблема должна быть разрешена с помощью изоляции транзакций, но на данный момент RefreshMode решает эти задачи. Значение этого свойства можно менять вручную между обращениями к базе данных.

Из всего многообразия, которое выдает IntelliSense на данный момент, работают только две опции:

  • AlwaysUseLocalValues – в этом режиме объекты всегда будут оставаться такими, какие они есть на клиенте, несмотря на то, что на сервере они могут быть уже изменены. Данный режим полезен для «распределенных» изменений множества связанных объектов, или для режима, когда существует выделенный «источник правды».
  • AlwaysReturnUpdatedValues – данный режим возвращает самые новые данные. Локальные данные будут переписаны при выполнении запросов затрагивающих измененные объекты.

Значение остальных опций, которые планируются к реализации в следующих выпусках базы (однако могут быть изменены или вовсе отменены):

  • TransparentRefresh –в фоновом режиме обновляются локально измененные объекты в соответствии с состоянием на сервере.
  • TransparentUpdateOnly – все изменения объекта пишутся напрямую в базу данных, без необходимости вызова функции Update.
  • UpdateAfterResolve – если объект уже существует в базе и локальные значения не совпадают с теми, что на сервере, будет вызван специальный метод для разрешения конфликтов. Обещают сделать очень скоро.

 Delete

Для удаления объектов из базы данных могут быть использованы два метода:

  • Delete – удаляет объект, который был получен из базы данных;
  • DeleteAll – удаляет объект и все зависимые объекты. Можно считать, что это аналог каскадного удаления.

С этим функционалом никаких премудростей нет. Все становится понятно и ясно из простого примера:

Продолжение следует…

Hard’n’heavy

Оставить комментарий