Eloquera IV

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

Хранимые процедуры

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

Хранимые процедуры могут рассматриваться как методы расширения к основной базе. Они пишутся с использованием C#, за что благодарность создателям, за то, что они не выдумали какой-либо свой интерпретируемый диалект для этого дела. Получается, что можно использовать все возможность .Net при написании процедур.

Итак, хватит слов, лучше показать, как создаются хранимые процедуры на деле.

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

Затем создаем класс, который нужен будет только на стороне сервера. При этом библиотеку с реализацией процедуры надо поместить в папку Lib в директории базы, либо настроить путь до библиотек с хранимыми процедурами с помощью параметра StoredProceduresPath.

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

После того, как вы закинули библиотеку с процедурами к серверу, на клиенте можно будет вызвать процедуру с помощью следующего кода:

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

Вообще, изначально, после новости про хранимые процедуры я подумал о функционале, который позволит мне сохранять длинные SQL запросы, с возможность передавать туда параметры, т.е. допустим, есть у меня такой вот код:

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

Однако я замечтался видимо о представлениях.

Наличие хранимых процедур в существующем виде решает более сложные задачи, нежели простое сохранение и повторный вызов запросов к базе. Стоит акцентировать внимание на том, что весь код выполняется на стороне базы. Т.е. с помощью процедур можно очень сильно сократить нагрузку на сеть, когда с помощью процедур можно более эффективно фильтровать данные на стороне сервера, по результатам фильтрования, к примеру, создавать новые элементы и сохранять их в базе. Я думаю, что нетрудно себе представить ситуацию, когда надо каким-либо значением дописать множество элементов из базы. При старом подходе пришлось бы выгрузить все элементы, создать выборку по условиям для обновления, обновить, и перегнать новые данные по сети обратно. Хранимая процедура решит такие задачи гораздо эффективнее.

Динамические объекты (Dynamic)

По утверждению разработчиков Eloquera они добавили немного магии к объектной базе и получили уникальный функционал и объект, который назвали Dynamic. Вы уже догадались, откуда ноги растут у этой фичи, и с чем она идеологически согласована в C#. Динамические объекты могут хранить в себе как структурированные данные, т.е. классы и структуры определенные вами в C# коде, так и произвольно составленные. При этом можно свободно представлять эти объекты в виде друг друга.

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

Преимущества, которые предоставляют динамические объекты:

  • Их легко создавать и использовать. Не надо беспокоиться о пропущенных полях и свойствах. Любое количество полей любого типа может быть добавлено в runtime.
  • Они автоматически определяют тип поля и работают с ним в соответствии с его возможностями и ограничениями. Динамические объекты в полной мере поддерживают индексацию.
  • Они могут ссылаться друг на друга и содержаться друг в друге.
  • Динамические объекты очень-очень быстрые.
  • Они  могут быть конвертированы на лету в «родные» объекты и обратно.
  • Для работы не требуется схема данных, что дает очень широкое поле для деятельности.
  • Движки для блогов, CMS, wiki
  • Профили и регистрация пользователей
  • Хранение истории записей
  • Случаи, когда данные надо фильтровать или агрегировать в runtime.
  • Приложения, оперирующие с переменных числом атрибутов разных типов.

Некоторые варианты использования:

 

По поводу последних двух пунктов надо пояснить, что имеются в виду различные программы, которые позволяют пользователям самостоятельно конструировать типы данных, динамически составляют интерфейс для каждого пользователя. Хранить такие данные в строгом виде нет никакой рациональной возможности без взрывной сложности. Использование Dynamic позволяет описывать такие типы в бесконечном многообразии и работать с ними в едином стиле.

Еще примером может служить веб 2.0, когда пользователи могут добавлять свои комментарии ко всему, ассоциировать материалы и так далее. С традиционными реляционными базами данных, жестким описанием классов, такие схемы невозможно или очень сложно будет реализовать.

Быстрый обзор работы с dynamic объектами

Структура динамических объектов может быть модифицирована  в любой момент вместе с содержащимися данными. Вместе с простотой использования, это дает более чем широкие возможности для эволюции данных.

Прошу заметить, что при использовании LINQ необходимо использовать d[“Price”]  для явного указания на постройку дерева выражений.

При работе с динамическими объектами есть возможность узнать все поля, которые содержит объект:

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

.,%][+-$!*()

Теперь можно более подробно рассмотреть аспекты работы c типом Dynamic.

Создание динамического типа

Создание происходит очень просто и легко в духе работы с массивами.

В квадратных скобках имя поля. Тип поля будет автоматически распознан базой, и при работе он будет учитываться в первую очередь. Т.е. если полю было присвоено булево значение, а потом попытаемся прибавить к нему цифру 5, то база будет ругаться на разные типы полей.

Для удаления поля надо присвоить ему значение null. Поля могут быть добавлены и удалены во время исполнения программы. Так же динамические объекты могут быть сконвертированы в родные объекты программы и наоборот.

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

 

Построение запросов

При построении SQL запросов доступны все возможности, описанные ранее, единственно, что меняется запрос к объекту. Т.е. надо указывать, что мы обращается к типу Dynamic.

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

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

Для построения LINQ запроса доступ к вложенным объектам осуществляется в духе работы с многомерными массивами. Запросы выше можно переписать следующим образом:

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

Операторы Distinct, Count, Top, Skip и тд в игре

Обновление и удаление элементов

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

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

Получение объекта и обновление его:

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

База великолепно работает и с новым .net типом dynamic.

При эволюционном подходе к жизни объектов, можно удалять не весь объект, а только одно поле. Т.е. ради миграции на новую версию объекта не надо будет удалять и пересоздавать старый объект. Пример использования:

Сейчас может прийти удивление и недоумение, а как же поиск полей и получение объектов по спец.полям как для обычных объектов. Хотя спец.полей нет, но есть функционал, который поможет узнать, объявлено ли поле с конкретным именем или нет  — это метод  ContainsKey. Пример:

И вариант для LINQ

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

hard’n’heavy!

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