flexberry / newplatform.flexberry.orm Goto Github PK

View Code? Open in Web Editor NEW

5.0 14.0 12.0 41.99 MB

Flexberry ORM source code

Home Page: https://www.nuget.org/packages/NewPlatform.Flexberry.ORM/

License: MIT License

C# 99.84% Shell 0.12% PowerShell 0.01% Dockerfile 0.03% Batchfile 0.01%

orm

newplatform.flexberry.orm's Introduction

Flexberry ORM

В этом репозитории располагается исходный код Flexberry ORM - фреймворка для объектно-реляционного отображения для Microsoft .NET.

Ключевые особенности

Концепция представлений (проекций).
Поддержка различных СУБД «из коробки».
Полная настройка названий таблиц, полей и т.п. в БД.
Первичные ключи произвольного типа.
Отображение в БД полей произвольных типов.
Перехват момента сохранения в БД и выполнение дополнительных действий.
Широкие возможности по кастомизации, включая возможность управления запросами.
Поддержка Mono и .NET Core 3.1 (отсутствие неуправляемого кода).

Использование

Для работы с Flexberry ORM требуется определение классов объектов данных и готовая БД. Данные классы можно реализовать вручную, но более удобный способ - использовать подход Model Driven Architecture и проектировать приложение в UML-редакторе Flexberry Designer с последующей генерацией полноценного кода на C# и SQL-скриптов для создания или модификации структуры таблиц БД. Данный подход не накладывает ограничений на разрабатываемые приложения, а напротив позволяет иметь хотя бы минимальное описание архитектуры приложения в виде UML-диаграмм. Для установки Flexberry ORM в проект следует воспользоваться NuGet-пакетом.

Структура проекта

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

Ядро ORM - базовые проекты, которые позволяют реализовывать объектно-реляционное отображение
- ICSSoft.STORMNET.DataObject - основной проект, в котором располагаются классы для работы с объектами данных, их связями, проекциями и пр..
- ICSSoft.STORMNET.Collections - реализация дополнительных типов коллекций, которые применяются в других проектах данного решения.
- ICSSoft.STORMNET.Business - основной проект с бизнес-логикой построения SQL-запросов и интерпретации полученных от СУБД результатов.
Проекты для поддержки конкретных СУБД
- ICSSoft.STORMNET.Business.MSSQLDataService - сервис данных для Microsoft SQL Server (в т.ч. SQL Azure).
- ICSSoft.STORMNET.Business.PostgresDataService - сервис данных для Postgres.
- ICSSoft.STORMNET.Business.OracleDataService - сервис данных для Oracle DB.
- Дополнительные сервисы данных располагаются в отдельных репозиториях, например, ClickHouseDataService или MongoDbDataService.
Проекты для поддержки языка запросов (Functional Language, LINQ)
- ICSSoft.STORMNET.FunctionalLanguage - проект с основными структурами встроенного языка запросов.
- ICSSoft.STORMNET.Business.ExternalLangDef - расширения для языка запросов, поддерживающие композитную агрегацию в моделях.
- ICSSoft.STORMNET.Business.LINQProvider - проект, с классами, реализующими поддержку LINQ-выражений.
Вспомогательные проекты
- ICSSoft.STORMNET.Tools - различные вспомогательные классы, например, позволяющие выполнять сериализацию-десериализацию объектов данных и пр..
- ICSSoft.STORMNET.UserDataTypes - дополнительные пользовательские типы данных, расширяющие набор, предлагаемый Microsoft .NET Framework.
- NewPlatform.Flexberry.ORM.CurrentUserService - проект, в котором определены классы, используемые для определения контекста исполнения - указание на текущего пользователя (применяется как базовый проект в прикладных системах, используется в сервисе пессимистических блокировок и системе полномочий).
- NewPlatform.Flexberry.ORM.UnityFactory - проект, реализующий интеграцию с Unity Container - DI.
- ICSSoft.STORMNET.Business.LockService - сервис пессимистических блокировок, позволяет избежать конфликтов при работе нескольких пользователей с одними и теми же данными.
Проекты для тестов
- NewPlatform.Flexberry.ORM.Tests - проект с автономными тестами.
- NewPlatform.Flexberry.ORM.IntegratedTests - проект с интеграционными тестами (для их исполнения требуются различные СУБД).
- NewPlatform.Flexberry.ORM.Tests.Objects - объекты для проекта с тестами
- NewPlatform.Flexberry.ORM.Tests.BusinessServers - бизнес-логика объектов проекта с тестами.

Целевая платформа

Поддеживается Microsoft .NET 4.5, 4.6.1, .NET Core 3.1, mono 4.6 и выше.

Тестирование

Тесты разделены на 2 проекта - автономные и интеграционные тесты. Для выполнения интеграционных тестов требуется наличие СУБД: Microsoft SQL, Postgres, Oracle. Соответствующие строки соединения задаются в конфигурационном файле проекта с интеграционными тестами. При выполнении тестов для каждого тестового метода создаётся временная БД (скрипты есть в проекте с интеграционными тестами). Структура данных для тестов сгенерирована при помощи Flexberry Designer, метаданные выгружены в виде crp-файла.

Документация

Документация разработчика размещается в разделе Flexberry ORM на сайте https://flexberry.github.io. Автогенерируемая документация по API размещается в ветке gh-pages и доступна пользователям по адресу: https://flexberry.github.io/NewPlatform.Flexberry.ORM/autodoc/develop/

Сообщество

Основным способом распространения Flexberry ORM является NuGet-пакет. Если во время использования этого фреймворка вы обнаружили ошибку или проблему, то можно завести Issue или исправить ошибку и отправить в этот репозиторий соответствующий Pool Request.

Доработка

Исправление ошибок приветствуется, технические детали можно выяснить в чате или непосредственно в описании Issue. Добавление новой функциональности рекомендуется согласовывать с авторами, поскольку принятие Pool Request в этом случае может быть затруднено.

Техническая поддержка

Авторы оставляют за собой право выполнять доработки и исправление ошибок самостоятельно без каких-либо гарантий по срокам. В случае необходимости получения приоритетной технической поддержки с фиксированными сроками, то условия проведения данной работы можно обговорить в частном порядке по E-Mail.

Ссылки

newplatform.flexberry.orm's People

Contributors

Stargazers

Watchers

Forkers

itservicecompany akovalevperm dslekomtsev fcherepanov vladgolovin rkapkannikov kn1k alexburmatov kd-timofeev archaim turbcool mariatkacheva

newplatform.flexberry.orm's Issues

Обработка кастомных типов с уведомлением об успешности транзакции

Цель

Кастомные типы, которые используют те или иные ресурсы нуждаются в получении информации о результате записи в БД: успешно или нет.

Функциональные требования

Требуется разработать интерфейс для кастомных типов в дополнение к интерфейсу из #59 для поддержки вызова методов, фиксирующих результат выполнения операции в БД.

Требования к реализации

Нужно несколько методов:

Метод, который вызовется непосредственно перед выполнением транзакции (все БСы уже сработали)
Метод, который вызовется в случае успешного завершения транзакции
Метод, который вызовется в случае неуспешного завершения транзакции

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

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

Исходный код

Этот репозиторий, сделать feature-ветку от develop.

Документация

Добавить статью в документацию (issue без статьи не закрывать)

Тесты

Реализовать тесты.

Примерная оценка трудоёмкости

16ч.

Некорректно работает сравнение с null для Nullable<bool> полей

Описание ошибки

Ограничение на вычитку объектов данных вида .Where(x=>x.NullableBoolField==null) работает некорректно. При построении LCS по такому ограничению получается функция ограничения вида {ISNULL ( = ( Approved) )}, что превращается в SQL вида ((case when ( ((Approved='1'))) then 1 else 0 end) IS NULL ), который некорректен.

Ожидаемое поведение

Должна строиться функция вида {ISNULL (Approved)} и SQL вида (Approved IS NULL). В более общем смысле ограничения на Nullable поля должна работать правильно.

Шаги воспроизведения

Создать объект с полем типа `bool?'
Записать в БД несколько записей с нуллами и без в заданном поле
Построить ограничение для него вида .Where(x=>x.NullableBoolField==null)
Убедиться, что ограничение не работает

Пути решения

Доработать LINQProvider для корректной поддержки данной ситуации.

Тесты

Реализовать интеграционные тесты по работе ограничений на Nullable полях.

Добавить поддержку типа данных JSON для полей DataObject-ов 🚀

В Flexberry ORM нужно добавить поддержку JSON-свойств в DataObject-ах. В .NET-классах для таких полей можно использовать тип JObject. В карте типов для PostgreSQL использовать тип JSONB. DataService должен автоматически сериализовывать/десериализовывать такие свойства, корректно проверять, является ли свойство Altered (по содержимому, а не по ссылке).

Некорректный порядок запросов в SQLDataService

Описание ошибки

Сейчас при выполнении запросов порядок таков, что сначала в SQLDataService выполняются Delete, потом Update и Create. Такой порядок может приводить к ошибкам:

Например, есть типы А и В. У обоих типов в одном обращении к сервису данных по разным объектам есть Delete и Update. В типе А удаляется запись. В типе В запись обновляется обнулением ссылки на удаляемый объект типа А. Корректный порядок: сначала обновление с обнулением ссылки, потом удаление. Фактический порядок, что сначала удаление, потом обновление, что приводит к ошибкам.

Возможно логично, чтобы сначала шло Update и Insert, потом Delete по таблице, но нужно продумывание данной ситуации на возможные побочные эффекты.

После реализации:

Раскомментировать интеграционный тест TestProperQueryOrder в проекте https://github.com/Flexberry/NewPlatform.Flexberry.ORM.
Оценить необходимость кода по обработке ситуации наличия ссылок иерархического типа (ссылка на самого себя) в SQLDataService.

Нормальное описание Exception-ов 🚀

Цель

Для всех исключений прописать вменяемое текстовое описание.

Функциональные требования

Нужно чтобы кто-то знающий нутро ORM прописал всем исключениям внятный Message. Чтобы было понятно что за ошибка произошла, с какими полями каких классов, как её поправить и так далее.

Исходный код

Вот в этом файле куча исключений без описания вообще: NewPlatform.Flexberry.ORM/ICSSoft.STORMNET.DataObject/Exceptions.cs

Доработать nuspec

Цель

Добавить возможность отказаться от изменений в конфигах приложений при установке NuGet-пакетов Flexberry ORM.

Функциональные требования

У пользователей NuGet-пакетов должна быть возможность отказаться от изменений в конфигах при обновлении технологических nuget пакетов.

Требования к реализации

В текущей реализации используется xdt-трансформация, которая слабо кастомизуется. Замена строк идёт без условных операций. Предлагается заменить xdt-трансформацию на ps1-скрипт при установке (удалении), который будет анализировать текущий конфиг и выполнять преобразование.
Отмена преобразований должна осуществляться при наличии комментария определённого вида в конфигурационном файле, например,

<!-- flexberry: disable nuget install config update -->

Исходный код

Проект на GitHub: NewPlatform.Flexberry.ORM
Ветка: `наследоваться от ветки develop

Документация

Ссылка - ссылка на документацию

Полезные ссылки, скриншоты

g=posts&m=13442#post13442

Применение к ORM принципов Dependency Injection

Данное issue формируется на основании rfc Flexberry/rfcs#23.

Цель

Изменить ORM для корректного применения принципов DI.

Функциональные требования

Настройка инъекций должна производиться в одном месте.
Из кода ORM и ODataService требуется убрать некорректное применение паттерна DI.

Требования к реализации

Взять ПР в ОРМ #181 по Dependency Injection и попробовать:
0) обновить ветку до свежей develop-версии.

убрать версии ПР определение текущего пользователя (это единственное место, которое прямо явно завязано на Unity и, судя по комментариям проверяющих, это место действительно можно выпилить).
выпустить с ветки ПР alpha-версию 7.2 (последняя - это 7.1 в beta, там ещё будут минимальные изменения и выпуск 7.1).
подключить эту альфа-версию к ODataService.
изменить ODataService при необходимости (там есть прямые инъекции в коде местами + есть ПР Flexberry/NewPlatform.Flexberry.ORM.ODataService#51).
сконфигурировать тесты ODataService (там есть startup) в 3 вариантах:

только с Unity,
только с встроенным DI (IServiceProvider),
с каким-то иным вариантом DI (autofac, ninject или иной, у которого реализована поддержка Microsoft...DependencyInjection). Посмотреть, какие особенности и сложности высветятся при запуске под разные фреймворки.

Потом
6) Целенаправленно по аналогии с ОРМ изменить прямые инъекции в ODataService (принять ПР Flexberry/NewPlatform.Flexberry.ORM.ODataService#51, если не сделано ранее).
7) Проверить и доделать пожелания по DI из RFC Flexberry/rfcs#23.

Вероятно, новая версия ORM будет 8.0.0, поскольку совместимость критично нарушится.

Документация

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

В версии ОРМа 5.1.0-beta* не применяется сортировка в методе SQLDataService.LoadStringedObjectView при использовании PostgresDataService

Описание ошибки

В версии ОРМа 5.1.0-beta* не применяется сортировка в методе SQLDataService.LoadStringedObjectView.
Как следствие в web forms приложении не работает сортировка WOLV'a.

Ожидаемое поведение

Сортировка должна работать.

Шаги воспроизведения

Определить lcs с сортировкой по полю.
Вызвать ds.LoadStringedObjectView
Сортировка не применилась.

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

Ошибка воспроизводится на следующей конфигурации:
Устройство: компьютер
ОС: (win, mono)
Браузер: (Chrome, FireFox, Edge, IE, Safari)
Версия технологического проекта: проверял на версии ОРМа >=5.1.0-beta13, на проекте используется PostgresDataService.

Пути решения

Посмотрел под дебагом - в PostgresDataService.ReadFirst идет обработка строки запроса, полученной из базового метода, но в итоге получается некорректная строка запроса - см. скриншот:

Скриншоты, полезные ссылки

Too long table name using PostgresDataService

PostgresDataService seems to have a issue generating aliases for non-standard PrimaryKeyStorage of master tables.

Error message: table name "ЗаявлениеНаСертифЗаявительЛично" specified more than once
Query: postgres_failure_long_alias.txt

Рефактор SQLDataService и всего обвеса

Цель

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

Функциональные требования

Далее будет много ссылок, которые ведут в основном на тэг v5.0.0 для защиты от изменений develop.

DI в полной мере:

Убрать использования UnityFactory.GetContainer (1, 2)
Убрать использование инстанций (1)
Убрать использование ConfigurationManager (1)

Разделить на несколько файлов:

Выделить делегаты в отдельные файлы (1)
Выделить методы LoadObject, LoadObjects, UpdateObject в отдельные partial файлы, аналогично методам UpdateObjects (1).
Выделить метод ConvertSimpleValueToQueryValueString (1) в сервис (связано с #59) (возможно вместе с методами ConvertValueToQueryValueString (1, 2)
Выделить методы по работе с IAuditService (1, 2) и ISecurityManager (1, 2, 3, 4, 5, 6) в отдельные partial файлы.
Выделить методы построения графа зависимостей (1, 2) в partial файл, а лучше в сервис.

Дробление сложных методов:

GenerateSQLSelect - выделить часть, отвечающую за сортировку (1) (требуется для #68)
UpdateObjectsByExtConn и UpdateObjects (1, 2) - выделить части метода, в которой исполняются команды (1, 2), а также подготовка массива возвращаемых объектов в AfterUpdateObjects (1, 2)

Изменение API:

GenerateQueriesForUpdateObjects (1) - заменить набор коллекций на класс, внутри которого будут скрыт этот бесконечный (1, 2) перечень параметров.
IDbConnection и IDbTransaction - заменить на DbTransactionWrapper (1)
Удалить метод CreateTransaction (1)

Требования к реализации

Сделать всё очень аккуратно, сломав обратную совместимость :)

Исходный код

Почти все интересные ссылки обозначены в первом разделе.

Проект на GitHub: https://github.com/Flexberry/NewPlatform.Flexberry.ORM
Ветка: develop (скорее всего после принятия #51)

Документация

Переписать документацию под новый API.

Тесты

Актуализировать тесты, которые сломаются из-за изменения API.

Примерная оценка трудоёмкости

40 часов.

Полезные ссылки, скриншоты

Во втором разделе.

Интерфейс для экспорта в Excel

Цель

Добавить интерфейс для сервиса экспорта в эксель (fast)

Требования к реализации

Необходимо, чтобы сервис ExportExcelODataServiceFast реализовывал свой отдельный интерфейс, использующий тип ObjectStringDataView

Проект на GitHub: https://github.com/Flexberry/NewPlatform.Flexberry.ORM
Ветка: develop

Оптимизация ORM PostgresDataService

Цель

Оптимизация запросов ORM PostgresDataService

Функциональные требования

При выполнении запроса к таблицам

Postgres берёт всю таблицу House, join'ит её со всей таблицей Client, сортирует по полю Clien.Surname, накладывает Limit.
Оптимально же было отсортировать по Client.Surname, применить Limit, заjoin'ить с таблицей House.

Исходный код

Проект на GitHub: https://github.com/Flexberry/NewPlatform.Flexberry.ORM
Ветка: develop

Полезные ссылки, скриншоты

g=posts&m=13295#post13295

Убрать лишний Update при вставке иерархической сущности

Убрать пропуск теста InsertHierarchyTest и починить проблему, которую он показывает.

Рефактор настроек IAuditService

Цель

Преобразовать способ получения настроек IAuditService. Использование блока AppSetting есть не самая лучшая идея, т.к. делает невозможным или сложным полноценное использование DI (читай, конфигурирование через Unity), в том числе нескольких сервисов аудита.

Функциональные требования

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

Требования к реализации

Удалить ICSSoft.STORMNET.Business/Audit/HelpStructures/ConfigHelper.cs (1), т.е. все настройки должны быть заданы в секции Unity.
Удалить статическую инстанцию AuditService (1) и статическую инициализацию (2)
Преобразовать метод ConfigHelper.ConstructProperAuditDataService таким образом, чтобы сервис данных разрешался через Unity по имени container.Resolve<IDataService>(dsName)
Преобразовать реализацию в пакете NewPlatform.Flexberry.Audit (1)

Исходный код

Проект на GitHub: NewPlatform.Flexberry.ORM
Ветка: develop (видимо, после принятия #50)

Документация

Преобразовать документацию.

Тесты

Преобразовать тесты аудита.

Примерная оценка трудоёмкости

80 часов

Полезные ссылки, скриншоты

Форум: default.aspx?g=posts&t=2559#post13438

Поддержка бизнес-серверов в XMLDataService

Сейчас в работе XMLDataService не производится вызов бизнес-серверов. Требуется, чтобы вызывались как это происходит в SQLDataService.

Функциональные требования

При выполнении CRUD-операций при использовании XMLDataService должны выполняться соответствующие бизнес-сервера (если определены).

Аналоги, примеры реализации

В SQLDataService происходят вызовы бизнес-серверов.

PersistUtcDates в IAuditService

Добавить свойство PersistUtcDates, реализованное в AuditService, в интерфейс IAuditService

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

Штука в целом опасная, т.к. может сильно замедлить работу.
Пояснение: DataObject оборачивается в прокси. Логика работы прокси: при вызове свойств DataObject'а проверяется загружено ли свойство. Если нет, оно автоматически выгружается, иначе возвращается существующее значение.
Зачем: бывают случаи, когда приходится множество раз догружать объект в зависимости от некоторых условий.
Как (где) можно реализовать: в прикладном проекте, затем перенести в технологию.

Батыров Нияз

Реализовать поддержку .NET Standard 2

Цель

Поддержать возможность использования в качестве базового фреймворка .NET Core наравне с .NET Framewok и Mono.

Функциональные требования

Сохранить обратную совместимость на уровне API. В крайнем случае выписать breakingchanges.

Требования к реализации

Для каждого проекта в солюшене нужно создать такой же, но для .NET Standard 2.

Исходный код

Этот репозиторий. В качестве основы использовать ветку develop. Для подсказки можно смотреть в реализацию ветки feature-dotnetcore2-v2.

Документация

Отразить изменения в документации

Тесты

Доработать тесты.

Аналоги, примеры реализации

Для подсказки можно смотреть в реализацию ветки feature-dotnetcore2-v2.

Примерная оценка трудоёмкости

16ч.

Полезные ссылки, скриншоты

Можно смотреть как сделано в LogService (PR).

Добавить тест на повторение ошибки генерации неправильного запроса

Описание ошибки

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

Ожидаемое поведение

Должен генерироваться рабочий SQL

Пути решения

Есть подозрение, что название поля из одного запроса попадает в другой из-за того, что название полей совпадает. Если выполнять запросы по отдельности, то всё выполняется как надо.
Также вместо вычислимого поля, с которым происходит проблема подставляется NULL.

Для начала предлагается написать юнит-тест на повторение ошибки

Исходный код

Проект на GitHub: Ссылка
Ветка: feature-wrong-query-test

Документация

Пример теста с многопоточностью

Скриншоты, полезные ссылки

g=posts&m=18767#post18767

Более полная поддержка LINQ

Цель

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

Функциональные требования

Выяснить, какие методы интерфейса IQueryable поддерживаются на данный момент в нашем LINQProvider, а какие - нет.
Реализовать тесты для полного покрытия методов IQueryable в нашем LINQProvider- проверяем, что всё работает корректно.
Под те тесты, которые не работают - дорабатываем LINQProvider.

Требования к реализации

Используем методику TDD - тесты вперёд.

Исходный код

Ветку с изменениями делаем от develop.

Документация

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

Тесты

(Немного тестов уже есть)[https://github.com/Flexberry/NewPlatform.Flexberry.ORM/blob/develop/NewPlatform.Flexberry.ORM.Tests/ICSSoft.STORMNET.Business.LINQProvider/TestLinqProvider.cs]
Надо постараться довести уровень покрытия тестами LINQProvider не ниже, чем 85%, а лучше 100%.

Вариативность сохранения изменений мастера в бизнес-сервере в зависимости от последовательности обновляемых объектов

Описание ошибки

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

Ожидаемое поведение

Поведение должно быть одинаковым вне зависимости от порядка объектов, передаваемых в UpdateObjects(). BusinesServer должен иметь приоритет при сохранении, поскольку его задача как раз заключается в корректировке данных, передаваемых на обновление.

Шаги воспроизведения

Нужен юнит-тест.

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

Ошибка присутствует во всех версиях ORM.

Пути решения

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

Можно посмотреть на реализацию в ветке feature-dotnetcore2-v2 - там, похоже, была решена эта проблема.

Исходный код

Ветка с юнит-тестом: fix-65-update-master-in-bs (само исправление, сделанное в ней не подходит, поскольку в такой реализации перестают срабатывать BS-ы детейлов при удалении агрегатора).

Тесты

Юнит-тест:

Примерная оценка трудоёмкости

8ч.

Use results "RowNumber" column when order is defined

SQL-queries generated by Flexberry ORM always contains calls to row_number() over(order by ...) inside nested subquery, so on the top level of generated queries we always have "RowNumber" column containing integer values representing desired order for the filtered set of records.
But Flexbery ORM doesn't use "RowNumber" colum and on the top level query execues ordering again, it seems to me that order by "RowNumber" column on the top level query will return just the same results, but executing will be faster.

При пейджинге с сортировкой в PostgresDataService одни и те же записи попадают в несколько страниц, а другие ни в одну 🚀

Описание ошибки

При пейджинге с сортировкой по полю, в котором есть повторяющиеся значения, некоторые записи попадают на несколько страниц, а некоторые ни на одну. Это связано с неуникальностью результатов отправляемого запроса и является официально задокументированным поведением PostgreSQL: https://stackoverflow.com/questions/13580826/postgresql-repeating-rows-from-limit-offset

Ожидаемое поведение

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

Шаги воспроизведения

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

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

БД: PostgreSQL
ORM: 5.0.0, 5.1

Пути решения

При генерации SQL-запроса в PostgresDataService для LCS, в котором заданы параметры пейджинга, добавлять в параметры сортировки последним параметром STORMMainObjectKey.
Попутно рассмотреть возможность отказа от row_number(), поскольку в PostgreSQL в нем нет необходимости.

Исходный код

Проект на GitHub: https://github.com/Flexberry/NewPlatform.Flexberry.ORM
Ветка в которую нужен будет PR: develop-v5.0.1 (от неё делаем ветку feature-67-...) и develop
Файл: https://github.com/Flexberry/NewPlatform.Flexberry.ORM/blob/develop/ICSSoft.STORMNET.Business.PostgresDataService/PostgresDataService.cs#L851

Тесты

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

Примерная оценка трудоёмкости

8ч

Скриншоты, полезные ссылки

https://stackoverflow.com/questions/13580826/postgresql-repeating-rows-from-limit-offset - пример ошибочного поведения при пейджинге
https://www.postgresql.org/docs/9.6/queries-limit.html - документация про операторы пейджинга в PostgreSQL для принятия решения о выпиливании row_number()
https://stackoverflow.com/questions/3125571/offset-vs-row-number - вопрос про сравнение offset и row_number в постгресе
Запросить ссылку на реализацию соответствующего метода на проекте Соцзащита

Чтение детейлов при удалении агрегатора производится вне транзакции

Описание ошибки

При удалении объекта, имеющего детейлов, происходит дочитка детейловых записей, чтобы отправить их на удаление вместе с агрегатором:
https://github.com/Flexberry/NewPlatform.Flexberry.ORM/blob/develop/ICSSoft.STORMNET.Business/SQLDataService/SQLDataService.cs#L4048
Как можно заметить, вызывается метод LoadObjects, а не LoadObjectsByExtConn.

Ожидаемое поведение

Должно осуществляться внутри транзакции.

Пути решения

Собственно, заменить в методе AddDeletedViewToDeleteDictionary метод LoadObjects на LoadObjectsByExtConn.

Исходный код

Представлены выше.

Тесты

Не уверен, что можно написать адекватный тест.

Объект может иметь статус «Altered» сразу после загрузки

Ожидаемое поведение

Сразу после загрузки объект имеет статус UnAltered.

Шаги воспроизведения

Запустить тест TestAlteredAfterLoading.

Исходный код

Ветка: fix-altered-after-loading.

Поддержка кастомных типов данных без доработок сервисов данных 🚀

Цель

Поддержка кастомных типов данных без доработок сервисов данных.

Функциональные требования

Требуется реализовать интерфейс, который позволит избавиться от необходимости уникальным образом обрабатывать кастомные типы данных на уровне самого сервиса данных. В качестве примера можно привести типы данных ГИСа, файловые типы. В данный момент без доработки DataService или без наследования невозможно ввести сложный тип. Надо преодолеть эту проблему. Обратная совместимость должна остаться.

Требования к реализации

В данный момент есть атрибут StoreInstancesInTypeAttribute, который задаёт соответствие кастомного типа типу данных в C#. Проблема в том, что этого недостаточно для формирования корректного SQL.
Реализация GisMSSQLDataService указывает на то, что нужно реализовать интерфейс, включающий в себя реализацию метода, аналогичного ConvertValueToQueryValueString и FunctionToSql.
Данный интерфейс должен использоваться ORM-ом для обработки кастомного типа, если тип поддерживает этот интерфейс.

Исходный код

Этот проект. Создать feature-ветку от develop.

Документация

Отразить изменения в документации по ORM.

Тесты

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

Аналоги, примеры реализации

Реализация должна позволить избавиться от наследников сервиса данных для Gis-типов: https://github.com/Flexberry/NewPlatform.Flexberry.ORM.GisMSSQLDataService и https://github.com/Flexberry/NewPlatform.Flexberry.ORM.GisPostgresDataService/.

Примерная оценка трудоёмкости

24ч

Реализовать тесты для IReferencesNullDelete

Описание ошибки

Есть подозрение, что интерфейс для удаления объекта с занулением связей IReferencesNullDelete не работает в версии ORM 5+. Нужно проверить это, реализовав интеграционный тест. Также надо проверить и второй интерфейс каскадного удаления.
Дополнительно требуется реализовать тест для удаления объекта с занулением через BS-ы, без использования этого интерфейса. Это важно для проверки корректности выстраивания запросов в правильном порядке. Опять же есть подозрение, что не всё работает корректно. Особое внимание следует уделить ситуации с иерархическими связями.

Ожидаемое поведение

Ожидаем, что удаление с занулением работает корректно.

Шаги воспроизведения

Нужно реализовать тесты в отдельной ветке, если они не работают, то починить это и сделать PR в develop. Объектную модель для тестов меняем по правилам: исправляем crp-файл, затем запускаем перегенерацию объеков данных через Docker.

Документация

Задокументировать эти интерфейсы.

Примерная оценка трудоёмкости

16ч.

Поддержка вычислимых полей в DataServiceExpression-ах

Функциональные требования

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

Требования к реализации

Для реализации можно анализировать выражения при построении запроса, и при наличии в нем вычислимых свойств с выражениями для сервисов данных, заменять вычислимое свойство на его выражение для соответствующего сервиса данных.

Исходный код

Information.GetSimpleStorageStructForView - наиболее подходящее место для анализа выражения.

Исходная ветка: develop

Документация

Нужно будет обновить статью «Нехранимые (вычислимые) свойства объекта данных».

Тесты

Конечно нужны.
Есть ветка feature-175881-add-dse-computed-master-test, там был добавлен тест.

Время

40 часов.

Разработка инструкций для корректной дочитки данных в бизнес-сервере

Цель

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

Функциональные требования

В связи с задачкой Flexberry/NewPlatform.Flexberry.ORM.ODataService#290, где будет реализован "нежадный ODataService", требуется реализовать инструкцию и примеры как правильно дочитывать данные в бизнес-серверах. Существует проблема с тем, что у объекта часть полей будет в состоянии изменения и эти изменения потерять нельзя, но дочитать объект из БД надо.

Требования к реализации

Возможно, надо доработать какой-нибудь метод прямо в ORM для дочитки (вроде бы что-то в этом направлении было уже даже сделано, но не на 100% готово).

Реализация CurrentWebHttpUser для netcoreapp

Цель

При переезде на netstandard2.0 в ORM версии 6.0 был удален CurrentWebHttpUser, т.к. netstandard не поддерживает (точнее, не содержит в себе) библиотеку System.Web.
Необходимо поддержать контекст текущего пользователя для netstandard2.0 (в среде исполнения netcoreapp) и net45.

Требования к реализации

Учесть особенности DI и доступа к HttpContext для netcoreapp, в т.ч. переосмыслить CurrentUserService
Наткнулся на один очень грязный способ реализации необходимого функционала: https://stackoverflow.com/a/40029302

Тесты

Нужны тесты под обе платформы.

Возможность влиять на поведение null-ов при сортировке 🚀

Цель

При сортировке по определенному полю может требоваться изменить поведение нуллов по-умолчанию (при сортировке по возрастанию нуллы в конце, при сортировке по убыванию нуллы в начале) на противоположное. Синтаксисы SQL некоторых СУБД поддерживают подобные настройки, например.
Необходимо поддержать такую настройку поведения сортировки в ORM.

Функциональные требования

Добавить в механизм построения sql-запроса возможность прикладному разработчику настроить поведение нуллов при сортировке
Реализовать поддержку данного поведения для PostgreSQL и MS SQL Server

Требования к реализации

Предлагается в SortOrder добавить еще два значения: AscNullsFirst и DescNullsLast
В PostgresDataService при построении запроса для случаев указанного нестандартного поведения нуллов использовать конструкцию [NULLS {FIRST | LAST}]
В MSSQLDataService аналогичной конструкции нет, поэтому предлагается использовать например такой вариант

Исходный код

Проект на GitHub: https://github.com/Flexberry/NewPlatform.Flexberry.ORM

Документация

Добавить описание новых вариантов сортировки в документацию, где упоминается LoadingCustomizationStruct, ColumnsSortDef, SortOrder

Тесты

Реализовать тесты, проверяющие построение SQL-запросов для новых вариантов сортировки

Примерная оценка трудоёмкости

8ч.

Полезные ссылки

Не обновляются автоинкрементные поля без перезагрузки приложения

Описание ошибки

Для автоинкрементных полей, которые были сгенерированы из Flexberry Designer и на сервере в БД отрабатывают, на клиенте автоматически обновление не происходит без перезагрузки приложения (повторной вычитки модели).

Ожидаемое поведение

Когда сервер измененное значение автоинкрементного свойства отдает в JSON-е в HTTP-ответе с актуальным значением автоинкрементного поля (он должен отдавать в ответе установленное сервером СУБД значение, это тоже надо проверить), эмбер должен автоматом его в сторе обновить, и оно должно подтягиваться само на форме.

Шаги воспроизведения

Склонировать клиентское и серверное приложение, а также скрипт создания БД (PostgreSQL) из этого репозитория.
Развернуть всё у себя локально
Создать нового сотрудника и сохранить
Узреть, что актуальный табельный номер сотрудника (сгенерированный на сервере) в заголовке формы подтягивается только после обновления страницы, а не автоматически после сохранения.

Пути решения

Предположения:

Возможно, сервер не отдает в ответе на HTTP-запрос на сохранение данных в JSON-ке сгенерированное значение автоинкрементного свойства (свойства number у модели сотрудника).
Если сервер отдает всё как надо, то нужно смотреть, попадает ли в стор новое значение сразу при обработке ответа с сервера. И если, вдруг попадает, понять, почему не срабатывает биндинг данных на форме в шаблоне.

Исходный код

https://github.com/Flexberry/ember-flexberry-data (PR создавать в ветку: develop)
или
https://github.com/Flexberry/ember-flexberry (PR создавать в ветку: develop)
или
https://github.com/Flexberry/NewPlatform.Flexberry.ORM.ODataService (PR создавать в ветку: develop-v5.2)
в зависимости от того, на каком уровне взаимодействия с сервером будет отловлена ошибка.

Документация

Про создание автоинкрементного атрибута можно почитать тут.
Про ожидаемое поведение подробнее можно почитать тут.

Тесты

Добавить интеграционный тест в CRUD операции на получение значения актуального значения автоинкрементного поля после сохранения модели на сервере сюда:
https://github.com/Flexberry/ember-flexberry-data/tree/develop/tests/unit/CRUD

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

Примерная оценка трудоёмкости

16 часов