flexberry / newplatform.flexberry.orm.odataservice

OData v4 server for .NET

Flexberry ORM ODataService

В этом репозитории располагается исходный код Flexberry ORM ODataService - серверного компонета для реализации публикации данных по протоколу OData V4 для Microsoft .NET Framework и .NET Core.

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

• Возможность публикации модели данных Flexberry ORM без необходимости доработки или генерации кода - достаточно иметь скомпилированную сборку с объектами данных.
• Широкие возможности по кастомизации, включая возможность управления запросами, передаваемыми в Flexberry ORM.
• Поддержка Mono (отсутствие неуправляемого кода).

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

Для работы с Flexberry ORM ODataService требуется наличие сборки с объектами данных Flexberry ORM. OData-сервер работает поверх WebApi, поэтому конфигурация выполняется в соответствующем стиле. Подробнее с конфигурацией можно познакомиться в документации.

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

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

• Реализация OData-сервера
  • NewPlatform.Flexberry.ORM.ODataService - основной проект, в котором располагаются классы для публикации с объектов данных по протоколу OData.
• Проекты для тестов
  • NewPlatform.Flexberry.ORM.ODataService.Tests - проект с интеграционными тестами (для их исполнения требуются различные СУБД).
  • NewPlatform.Flexberry.ORM.ODataService.Tests(Objects) - объекты для проекта с тестами
  • NewPlatform.Flexberry.ORM.ODataService.Tests(BusinessServers) - бизнес-логика объектов проекта с тестами.

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

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

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

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

Сообщество

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

Доработка

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

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

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

Ссылки

• Информация на официальном сайте
• Документация
• Лицензия (MIT)
• Лог изменений
• Установить через NuGet
• Gitter чат
• E-Mail

newplatform.flexberry.orm.odataservice's Issues

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

Цель

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

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

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

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

Не ломать обратную совместимость, проверить производительность.

Исходный код

Этот репозиторий.

Тесты

Тесты должны работать. Можно добавить тест, который будет учитывать генерирующийся SQL - проверять, что нет лишних полей.

Политика перехода к .NET Standard 2.0

Цель

Перейти на разработку под .NET Standard 2.0

План перехода по версиям

1. Версия 5.1 включает в себя все текущие наработки ветки develop. Базовые сборки OData версий 5.7, платформа .NET Framework 4.5.
2. Версия 6.0 отличается от версии 5.1 тем, что собрана под .NET Framework 4.6.1.
3. Версия 6.1 отличается от версии 6.0 тем, что базируется на сборках OData 7.1.0 и ORM 6.0.
4. Версия 6.2 отличается от версии 6.1 тем, что собрана под .NET Standard 2.0, включая 2 дополнения под ASP.NET 4.5 и ASP.NET Core 3

Политика работы с ветками

Ветка develop блокируется на время с целью стабилизации. Для версии 5.1 рабочей веткой становится develop-v5.1-beta, которая будет накапливать изменения для последующего применения поверх версии 6.2, промежуточные версии 5.1-beta будут выпускаться с неё.

Ветки для перехода к .NET Standard будут именоваться соответственно версиям:

1. develop-v5.1
2. develop-v6.0
3. develop-v6.1
4. develop-v6.2

В эти ветки делаем PR-ы. Сами они ни с чем сливаться не должны.
Все эти версии планируется выдать параллельно. После этого ветка develop-v6.2 будет переименована в develop (либо force push без merge).
Изменения, накопленные в ветке develop-v5.1-beta нужно будет вручную применить на всех 4-х ветках.

Поддержать VS2019: убрать использование CodeContracts

Цель

Заменить использование CodeContracts на явную проверку аргументов, поскольку они более не поддерживаются со стороны Visual Studio 2019.

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

1. Удалить все упоминания CodeContracts.
2. Использовать явную проверку аргументов.

Тесты

Тесты должны проходить.

Запрос без явного указания select'а с набором свойств обходит фильтрацию делегатом PropertyFilter и пытается вытянуть все свойства объекта.

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

Запрос без явного указания select'а с набором свойств обходит фильтрацию делегатом PropertyFilter и пытается вытянуть все свойства объекта.

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

Ожидается, что фильтрация применится на такой запрос.

Поддержать OData $batch запросы

Цель

Требуется поддержать запрос $batch с целью поддержки обновления нескольких объектов в одной транзакции.

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

1. $batch запрос должен обрабатываться согласно спецификации OData v4.

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

1. Реализовать с использованием стандартных средств, предоставляемых библиотеками Microsoft.

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

Дополнить документацию.

Тесты

Подготовить тесты.

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

• Опираться в т.ч. на постановку в клиентской логике

Поддержка ограничений на детейлы мастера в ODataService

Цель

Надо поддержать возможность построить ограничение на детейлы мастера.

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

LCS позволяет строить ограничения на детейлы мастера. Нужно поддержать в ODataService эту возможность, тем более, что OData допускает такой фильтр.

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

Нужно написать тест, в котором будет URL с таким ограничением. Посмотреть как DataObjectController его обрабатывает. Добавить недостающую обработку, чтобы получился LINQ expression, который ожидается в ORM.

Исходный код

Ветка: feature-43-filter-master-details

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

Дописать документацию.

Тесты

Использовать подход TDD.

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

• Тесты в ORM с ограничениями на детейлы мастера

При выполнении batchUpdate инстанции объектов для одного PK различаются

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

При выполнении batchUpdate отдельные запросы идут без общего DataObjectCache. Это приводит к тому, что создаются разные инстанции с одинаковыми ключами.

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

В рамках batchUpdate все инстанции объектов должны быть в единичном экземпляре. Это позволит нормально обработать объекты в бизнес-серверах.

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

Обновлять отдельными запросами в рамках одного batchUpdate объект и его мастера. В бизнес-сервере инстанции мастера по ссылке и в ObjectsToUpdate будут разными.

Пути решения

Добавить DataObjectCache и передавать его между запросами в рамках batchUpdate.

Возможность внедрения зависимостей в обработчики одата-функций и экшенов

Цель

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

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

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

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

Предлагается каким-то образом переработать регистрацию и объявление одата-функций и экшенов, чтобы это были не делегаты, а, например, наследники каких-то generic-классов с методом execute(). При вызове с клиента одата-функции/экшена должно производиться создание соответствующего обработчика посредством di-контейнера и внедрение всех зависимостей его средствами.

Исходный код

Проект на GitHub: https://github.com/Flexberry/NewPlatform.Flexberry.ORM.ODataService
Ветка: develop
Классы: https://github.com/Flexberry/NewPlatform.Flexberry.ORM.ODataService/tree/develop/NewPlatform.Flexberry.ORM.ODataService/Functions

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

Необходимо исправить документацию по регистрации одата-функций/экшенов

Тесты

Необходимо доработать тесты, касающиеся функциональности одата-функций и экшенов.

Перенести исправление в PR #225 в v6.0 и v6.1

Цель

Нужно перенести исправления в PR #225 в v6.0 и v6.1.

Проблемы с порядком вызова BS в случае мастеровой связи

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

Когда требуется обновить мастера в BS-е основного объекта, то BS мастера должен выполняться после основного объекта, иначе изменения не срабатывают.

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

Если связь - ассоциация, то передавать мастера после основного объекта. Для агрегации оставить прежний порядок.

Добавить поддержку фильтра сравнения двух полей типа дата без учёта времени.

Цель

Добавить поддержку фильтра сравнения двух полей типа дата без учёта времени.

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

В настоящее время поддерживаются фильтры для полей типа дата вида "date(Поле1) < 2021-10-01", "2021-10-01 < date(Поле1) ", "Поле1 < Поле2", однако нет поддержки ситуации сравнения двух полей типа дата без учёта времени, то есть "date(Поле1) < date(Поле2)".

• В стандарте OData есть такой вариант http://docs.oasis-open.org/odata/odata/v4.01/odata-v4.01-part1-protocol.html#sec_SystemQueryOptionfilter: "date(StartTime) ne date(EndTime)".

Исходный код

Основная обработка конструкции типа "date(Поле1) < 2021-10-01", "2021-10-01 < date(Поле1)" осуществляется в классе NewPlatform.Flexberry.ORM.ODataService.Expressions.FilterBinder.

date привязывается в методе "BindDate", однако при поверхностном просмотре кода создалось ощущение, что информация о наличии "date" никуда не заносится.

Преобразование для отбрасывания части со временем происходит вероятно в методе "private Expression CreateBinaryExpression(BinaryOperatorKind binaryOperator, Expression left, Expression right, bool liftToNull)":

"if (leftUnderlyingType == typeof(DateTime) && rightUnderlyingType == typeof(DateTimeOffset))
{
right = DateTimeOffsetToDateTime(right);
}
else if (rightUnderlyingType == typeof(DateTime) && leftUnderlyingType == typeof(DateTimeOffset))
{
left = DateTimeOffsetToDateTime(left);
}

        if ((IsDateOrOffset(leftUnderlyingType) && IsDate(rightUnderlyingType)) ||
            (IsDate(leftUnderlyingType) && IsDateOrOffset(rightUnderlyingType)))
        {
            left = CreateDateBinaryExpression(left);
            right = CreateDateBinaryExpression(right);
        }"

Однако ситуация, где у оператора сравнения с двух сторон указаны атрибуты типа дата с date здесь не обрабатывается.

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

В документации указано, что запросы такого рода не обрабатываются odata-adapter. После реализации эту информацию нужно убрать.

Тесты

В проекте https://github.com/Flexberry/ember-flexberry-data выключены тесты в "odata-reading-date-predicates-timeless-test". После реализации включить.

AfterUpdate при batch отрабатывает не вовремя

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

После обновления конкретного типа объектов необходимо выполнить некоторые действия, для этого заведено следующее:
manageToken.Events.CallbackAfterUpdate = ODataEvents.AfterUpdate;

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

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

Событие AfterUpdate должно учитывать контекст исполнения batch и вызываться только после реального исполнения ds.UpdateObjects.

Тесты

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

batchUpdate в mono 5.* теряет HttpContext.Current

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

В среде исполнения mono версии 5 и выше операция batchUpdate теряет HttpContext.Current. В частности, из-за потери контекста перестают работать полномочия и аудит.

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

Контекст не должен теряться.

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

Запустить тестовое приложение под mono 5.18 или 5.20.

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

mono 5.*

Пути решения

Разобраться что происходит с контекстом.

Исходный код

Этот репозиторий.

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

flexberry.github.io

Тесты

Если возможно, то подготовить тест.

Ломается сериализация при добавлении PseudoDetail

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

При добавлении псевдодетейлов на бэк при отправке batch-запроса при сохранении некоторых объектов стала появляться ошибка

"'EdmEntityObject' cannot be serialized using the ODataMediaTypeFormatter."
message: "'EdmEntityObject' cannot be serialized using the ODataMediaTypeFormatter."
stack: " в System.Web.OData.Formatter.ODataMediaTypeFormatter.GetSerializer(Type type, Object value, IEdmModel model, ODataSerializerProvider serializerProvider)
в System.Web.OData.Formatter.ODataMediaTypeFormatter.WriteToStream(Type type, Object value, Stream writeStream, HttpContent content, HttpContentHeaders contentHeaders)
в System.Web.OData.Formatter.ODataMediaTypeFormatter.WriteToStreamAsync(Type type, Object value, Stream writeStream, HttpContent content, TransportContext transportContext, CancellationToken cancellationToken)
--- Конец трассировка стека из предыдущего расположения, где возникло исключение ---
в System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
в System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
в System.Web.OData.Batch.ODataBatchResponseItem.d__0.MoveNext()
--- Конец трассировка стека из предыдущего расположения, где возникло исключение ---
в System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
в System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
в System.Web.OData.Batch.ODataBatchContent.d__0.MoveNext()
--- Конец трассировка стека из предыдущего расположения, где возникло исключение ---
в System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
в System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
в System.Web.Http.WebHost.HttpControllerHandler.d__22.MoveNext()"

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

Не должен падатьbatch-запрос при создании и сохранении нового ProcessParticipant

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

Подробно здесь ?g=posts&m=19268#post19268

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

Версии:
Flexberry.ORM: 5.0.2
Flexberry.ORM.ODataService: 5.1.0-beta02

ember-cli: 2.4.3
ember-flexberry: 2.3.0-beta.0

Пути решения

<Описание того, в чём заключается проблема>
<Подсказки программисту как исправить ошибку>

Исходный код

https://github.com/Flexberry/NewPlatform.Flexberry.ORM.ODataService
Унаследоваться от develop

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

Тесты

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

?g=posts&m=19268#post19268

Перенести класс DataServiceExtensions в ORM

Цель

Реализовать методы расширения, появившиеся в ODataService непосредственно в самих классах ORM.

Ошибка при сохранении decimal

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

Есть поле типа decimal(20,6).
На форме редактирования ввожу значение 0.0008, всё нормально сохраняет.
Если ввести 0.00008, то падает с ошибкой :

message: "!VbJ8y!Cannot convert the literal '8E-05' to the expected type 'Edm.Decimal'. Ploc Pl!"
stack: " в NewPlatform.Flexberry.ORM.ODataService.Controllers.DataObjectController.ReplaceOdataBindNull() в NewPlatform.Flexberry.ORM.ODataService.Controllers.DataObjectController.Patch(Guid key, EdmEntityObject edmEntity)"

На бэке поле: public virtual System.Decimal? LoadOnGvsContr
В базе поле: (decimal(20,6),NULL)

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

Сохранение и обработка Decimal заданной длины

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

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

Пути решения

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

Исходный код

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

Тесты

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

?g=posts&m=19504#post19504

Некорректное поведение при использовании параметра count=true

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

В ситуации, когда BeforeGet возвращает false, но в url запроса используется параметр count=true, oDataController отдает все объекты

Обнаружена на версии 5.2.0, но судя по коду, должно повториться и на последней версии тоже

В нашей версии это код из метода ExecuteExpression, в последней версии аналогичный код встречается в методе - PrepareDataObjects:

       if (QueryOptions.Count != null && QueryOptions.Count.Value)
       {
               IncludeCount = true;
               ...
               _objs = LoadObjects(_lcs, out count, callExecuteCallbackBeforeGet, true); // т.к. BeforeGet вернул false, то загрузки не происходит и count остается равным -1
               ...
               callExecuteCallbackBeforeGet = false;
               ...
       }

       if (!IncludeCount || count != 0) // т.к. count == -1, то мы попадаем в это условие
           _objs = LoadObjects(_lcs, out count, callExecuteCallbackBeforeGet, false); // а т.к. callExecuteCallbackBeforeGet  == false, то BeforeGet больше не вызовется и не вернет false. Отдаются все объекты

Метод LoadObjects:

       ...
        count = -1;
        if (callExecuteCallbackBeforeGet)
            doLoad = ExecuteCallbackBeforeGet(ref lcs);
        if (doLoad) // сюда не попадаем
        {
            if (!callGetObjectsCount)
            {
                dobjs = _dataService.LoadObjects(lcs, DataObjectCache);
            }
            else
            {
                count = _dataService.GetObjectsCount(lcs);
            }
        }
       ...

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

Использование параметра count не должно приводить к игнорированию результатов метода BeforeGet

Не соответствующее спецификации поведение нуллов при сортировке

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

По спецификации OData при сортировке Null values come before non-null values when sorting in ascending order and after non-null values when sorting in descending order. Сейчас в ODataService поведение не соответствует спецификации.
Более того, ей не соответствует и исходная реализация. Это связано с тем, что для SQL поведение по умолчанию нуллов при сортировке противоположное.

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

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

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

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

Пути решения

В ORM создана задача на добавление возможности изменить поведение нуллов при сортировке.
Необходимо добавить в механизм построения LCS по параметрам odata-запроса возможность настройки поведения нуллов при сортировке.

Тесты

Предлагается покрыть тестами механизм построения LCS по параметрам odata-запроса

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

• https://docs.oasis-open.org/odata/odata/v4.01/csprd06/part1-protocol/odata-v4.01-csprd06-part1-protocol.html#_Toc21423809
• OData/odata.net#1592
• Flexberry/NewPlatform.Flexberry.ORM#211

Проблема с сохранением объекта если есть наследование детейлов

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

Если детейлы содержат иерархию наследования, то сохранение не срабатывает из-за логики добавления детейла в агрегатор.

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

Сохранение должно работать.

Регистрации функции без возвращаемого результата в качестве действия

Хочется иметь возможность зарегистрировать функцию для одата-экшена, которая не возвращает никаких результатов.
Не разобрался как это сделать с использованием класса NewPlatform.Flexberry.ORM.ODataService.Functions.Action, можно возвращать null, но кажется что это не совсем то что нужно.

NewPlatform.Flexberry.ORM.ODataService/Tests/NewPlatform.Flexberry.ORM.ODataService.Tests/Functions/ActionsTest.cs

Lines 56 to 71 in d53f925

	if (!container.IsRegistered("ActionVoid"))
	{
	parametersTypes = new Dictionary<string, Type> { { "entitySet", typeof(string) }, { "query", typeof(string) } };
	container.Register(new Action(
	"ActionVoid",
	(queryParameters, parameters) =>
	{
	var type = queryParameters.GetDataObjectType(parameters["entitySet"] as string);
	var uri = $"http://a/b/c?{parameters["query"]}";
	var lcs = queryParameters.CreateLcs(type, uri);
	var dobjs = dataService.LoadObjects(lcs);
	return null;
	},
	typeof(void),
	parametersTypes));
	}

При регистрации экшена с использованием делегата и метода RegisterAction, регистрация выполняется без ошибок, но вызвать его не получается, одата отвечает ошибкой 404 Not Found.

Если такая функция была выполнена без ошибок, ответ должен быть с кодом 204 No Content.
Сейчас код ответа 200 OK, даже при отсутствии тела ответа, возможно поэтому, при обработке он считается ошибочным.

Нельзя вернуть клиенту ошибку с кодом отличным от 500

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

HttpResponseException из OData-функции оборачивается в Internal Server Error.

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

Если в Odata-функции (или экшене) бросается HttpResponseException, содержащий HttpResponseMessage c ODataError и определенным кодом, клиенту должно возвращаться HttpResponseMessage.
Если в бросаемом HttpResponseException нет ODataError, исключение должно обрабатываться стандартно - 500-ой ошибкой.

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

1. Создать и зарегистрировать OData-функцию
2. Бросить внутри этой функции HttpResponseException с ODataError и HttpStatusCode, отличным от Internal Server Error
3. Послать запрос на выполнение функции
4. На клиент придет ошибка с 500 кодом

Пути решения

Проблема заключается в том, что в контроллере все ошибки, возникающие при выполнении OData экшенов и функций, обрабатываются независимо от их типа и в каждом случае создается http-ответ с 500 кодом по умолчанию.
Необходимо добавить обработку для ошибок типа HttpResponseException, содержащих ODataError.

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

• HttpRequestMessageExtensions.CreateErrorResponse
• ODataError
• Пример вызова исключения в ODataController

Исходный код

• DataObjectController.PostODataActionsExecute - метод, выполняющий OData экшн.
• DataObjectController.GetODataFunctionsExecute - метод, выполняющий OData функцию.

Ветка: <develop>

Тесты

Нужно добавить тесты на проверку проброса ошибки.

Время

10 часов (2 часа - исправление, 8 часов - тесты)

Поддержка псевдодетейлов со стороны ODataService

Цель

Требуется поддержать возможность добавления связей "псевдодетейл" (обратная ассоциация, фиктивная детейловая связь, фиктивные NavigationProperty type="Collection(xxx)") и их адекватную обработку при соответствующих запросах со стороны клиента.

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

1. Реализовать метод для добавления фиктивных NavigationProperties в EDM-модель. Вызываться этот метод должен из прикладного кода в момент конфигурации ODataService (в методе ODataConfig.Configure()).
2. При обработке клиентских запросов, в которых используются фиктивные NavigationProperties использовать методы обработки псевдодетейлов на уровне LINQProvider в соответствии с документацией к последнему.
3. ODataService не должен давать получать данные по этому свойству, т.е. при добавлении этого свойства в select ODataService должен генерировать ошибку.

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

Согласно описанию поддержки псевдодетейлов со стороны LINQProvider, метод для добавления фиктивных NavigationProperties должен принимать следующие параметры:

1. Тип класса, который будет псевдодетейлом.
2. Имя связи от псевдодетейла к мастеру.
3. Имя связи от мастера к псевдодетейлу (псевдосвойство) - собственно то, что станет фиктивным NavigationProperty.

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

На уровне ODataService нужно предусмотреть сохранение информации о том, какие свойства являются псевдодетейлами, поскольку они требуют особой обработки со стороны DataService.
В логике обработки вызовов в DataObjectController требуется анализировать необходимость отдельной обработки псевдодетейлов, а также проверять не запрошена ли эта коллекция (если запросили, то сгенерировать ошибку).

Исходный код

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

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

Доработать документацию в разделе про ORM ODataService.

Тесты

Реализовать тесты в соответствии с имеющимися подходами.

Убрать в nuspec зависимость от NewPlatform.Flexberry.UserSettingsService

В ветке develop-v5.1 в nuspec файле есть зависимость на NewPlatform.Flexberry.UserSettingsService. Но в самом проекте зависимостей на этот пакет нет. Нужно проверить и убрать его из nuspec.

Вызов события CallbackBeforeUpdate для объекта без изменений

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

В приватном методе DataObjectController.UpdateObject после рекурсивной сборки объектов данных из EDM (метод GetDataObjectByEdmEntity, линк) вызываются события ExecuteCallbackBeforeCreate и ExecuteCallbackBeforeUpdate для всех объектов, которое были вытянуты методом GetDataObjectByEdmEntity, линк.
Событие отрабатывает так же и для объектов, которые не были изменены, например, мастеровой объект.

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

Вопрос: так и задумано, что объекты, которые не были изменены, обрабатываются методом ExecuteCallbackBeforeUpdate?
Если данное поведение не является корректным, то исключить неизмененные объекты с перечня, для которого будет инициировано событие.

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

• Подписаться на событие CallbackBeforeUpdate
• Отправить POST или PATCH запрос для объекта с мастером
• Будет инициировано событие CallbackBeforeUpdate для мастера.

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

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

Создал пользовательский тип (по этому гайду).
После этого пытаюсь сравнить его вот так: DS.Query(...).Where(<Мой тип> != null).
Получаю ошибку: ICSSoft.STORMNET.Business.LINQProvider.Exceptions.UnknownTypeException : Неизвестный тип операнда <Мой тип>.
Записал пример в этот тест.

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

Пользовательские типы должны работать в Query

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

Ошибка воспроизводиться в тесте #81

Пути решения

Исходный код

Проект на GitHub: <https://github.com/Flexberry/NewPlatform.Flexberry.ORM.ODataService>
Ветка: <https://github.com/Flexberry/NewPlatform.Flexberry.ORM.ODataService/pull/81>

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

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

Тесты

#81

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

*<Сколько времени в часах может понадобиться на решение поставленной задачи среднему

Доступ к свойствам DataObjectController в событиях

Цель

Т.к. православным способом подмены сервиса данных внутри DataObjectController'а считается кастомная реализация IHttpControllerActivator, необходима возможность в событиях получиться доступ до свойств\полей DataObjectController'а: _dataService, _dataObjectCache, _model и другие

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

1. Переделать приватные поля _dataService, _dataObjectCache, _model в публичные свойства.
2. Передавать инстанцию текущего DataObjectController'а в каждое событие.

Исходный код

Действия производить в рамках текущего состояния develop данного репозитория.

Тесты

Преобразовать тесты под новый API

Проблемы при чтении объекта по ключу

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

В ответе сервиса, свойства мастера возвращаются как null, при запросе объекта по первичному ключу.

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

Если в запросе не указана опция $select, должен возвращаться объект со всеми собственными свойствами, иначе, только перечисленными в опции.
Если в запросе указана опция $expand, возвращаемый объект должен включать ссылочные свойства объекта, указанные в опции. Свойство указанное в опции $expand, может содержать вложенную опцию $select, с теми же правилами.
Примеры:

• без опций
• $select
• $expand
• $select & $expand

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

Для воспроизведения можно использовать текущую версию пакета.

Пути решения

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

Исходный код

• DataObjectController.GetGuid - метод обрабатывающий запрос объекта по ключу.
• Tests/NewPlatform.Flexberry.ORM.ODataService.Tests/CRUD/Read - классы с тестами чтения объектов.

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

Тесты

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

Время

16 часов (4 часа - исправление, 12 часов - тесты).

Проблема с request header "Prefer" в IIS 10

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

При настройке приложения в IIS 10 столкнулись с проблемой обработки заголовка Prefer.

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

В запросе есть Prefer: return=representation и это не приводило к проблемам раньше.

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

1. Отправляем POST-запрос с Prefer: return=representation
2. Получаем ошибку:

• Значение не может быть неопределенным. Имя параметра: source
• в System.Linq.Enumerable.Contains[TSource](IEnumerable`1 source, TSource value, IEqualityComparer`1 comparer) в NewPlatform.Flexberry.ORM.ODataService.Controllers.DataObjectController.TestPreferMinimal() в NewPlatform.Flexberry.ORM.ODataService.Controllers.DataObjectController.Post(EdmEntityObject edmEntity)

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

IIS 10, Windows Server 2019 Std

Пути решения

Вероятно, можно проверять распарсился ли адекватно заголовок и только после этого выполнять Contains().

Исходный код

• Ссылка

Добавить фабрику сервиса данных

Цель

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

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

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

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

Для реализации данной возможности необходимо:

• добавить в DataObjectController виртуальный метод IDataService GetDataService(Type), который будет возвращать экземпляр сервиса данных в зависимости от использованного конструктора:
  return _dataService;
• все обращения к приватному полю _dataService заменить на метод GetDataService.

Опционально (т.к. будет достаточно для переопределения на прикладном проекте):

• изменить тело метода GetDataService на: return _dataService ?? _factory.Create(type);
• выделить интерфейс IDataServiceFactory с один методом IDataService Create(Type)
• добавить новый конструктор для DataObjectController:
  public DataObjectController(IDataServiceFactory, DataObjectCache, DataObjectEdmModel ,IEventHandlerContainer, IFunctionContainer)
• существующий конструктор пометить атрибутом [InjectionConstructor] для обратной совместимости

Тесты

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

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

• EaisDataServiceSelector - ссылка на реализацию данного паттерна в ЕАИС

Выбор и реализация оптимального механизма конфигурирования Flexberry-приложений под .net core .

Цель

Выбрать и реализовать оптимальный механизм конфигурирования Flexberry-приложений под .net core .

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

Библиотеки NewPlatform.Flexberry широко используют Unity DI для инициализации своих компонентов.
Unity DI использует файл конфигурации в формате xml. Такой же формат файла конфигурации используется log4net в составе NewPlatform.Flexberry.LogService .

В то же время приложения .net core имеют свой встроенный DI, в общем случае конфигурируемый кодом. Само приложение .net core по умолчанию конфигурируется файлом в формате json.

Необходимо определиться, один (встроенный DI либо Unity DI) или два (встроенный DI + Unity DI) следует использовать в приложениях на платформе Flexberry под .net core, а так же определиться с реализацией конфигурирования через файлы конфигурации и, соответсвенно, с номенклатурой конфигурационных файлов (один формата json либо xml, один формата json для стандартного конфигурирования .net core приложения + app.config для конфигурирования log4net и Unity DI, либо один формата json + отдельный .config для каждой подсистемы, конфигурируемой через xml.

Следует учитывать, что выбор, основанный на использовании только встроенного DI, скорее всего повлечет за собой модификацию Flexberry-библиотек, в настоящее время использующих Unity DI.

Исходный код

В качестве исследования было реализовано конфигурирование ODataService backend'а с двумя (встроенный + Unity) DI и двумя файлами конфигурации (application.json + app.config).

Указанная реализация выявила возможность неочевидного переопределения ЖЦ объекта между DI-контейнерами разных типов (в частности, инициализация экземпляра IDataService через Unity DI с ЖЦ singleton и последующее получение экземпляра IDataService через встроенный DI с ЖЦ scoped вызовом DataServiceProvider.DataService фактически для экземпляра IDataService определяет ЖЦ singleton).

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

Цель

Возможность выделить работу с файлами в отдельный сервис.

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

На текущий момент для хранения файлов у нас используется технологические WebFile и соответствующий File-контроллер в Odata-бэкенде, который складывает файлы рядом с собой в файловую систему.
Соответственно доступ к этим файлам можно получить либо через тот же контроллер, либо через файловую систему.
Минусы - нехарактерная нагрузка на Odata, сложность организации распределённой работы нескольких сервисов с хранящимися файлами.

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

Текущий интерфейс сервиса (загрузка файла, получение файла по ключу) оставить (сохранится работоспособность файлового ember-компонента) + дополнить методами получения списка файлов, удаления файла.

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

Возможно, достаточно будет вынести удаление файлов в соотв. fileprovider из DataObjectController'a
и реализовывать прикладной файлпровайдер + кастомный файл-контроллер.

Исходный код

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

Упорядочить параметры в заголовке Content-Type ответов от ODataController-а

Цель

Сейчас многие, хотя и не все, ответы от ODataController-а возвращаются с Content-Type: application/json; odata.metadata=minimal; odata.streaming=true; charset=utf-8. При проксировании этих запросов с помощью nginx не производится компрессия ответа. При этом, если переупорядочить содержимое заголовка к виду application/json; charset=utf-8; odata.metadata=minimal; odata.streaming=true;, то nginx распознает такой заголовок нормально и сжимает ответ. Необходимо добавить в ODataService функциональность по изменению возвращаемого заголовка Content-Type.

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

Учесть вариант реализации ODataBackend-а как в виде обычного ASP.Net Web Api проекта, так и в виде OWIN-проекта.

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

В случае OWIN есть готовый middlware с данной функциональностью на прикладном проекте.
Для обычного WebApi видимо нужно реализовать соответствующий HttpHandler.

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

Добавить описание добавленных middleware/handler-ов в документацию по ODataService-у.

Тесты

Реализовать тесты, проверяющие, что Content-Type преобразуется к требуемому виду.

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

Прикладной проект

Don't call BS of aggregator when change details

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

Когда изменяется детейл, то не вызывается BS агрегатора.

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

BS агрегатора должен вызваться.

Исходный код

Ветка: fix-call-agregator-bs-on-change-details

Добавить параметр на количество вложений в batch-запрос

Цель

Предоставить возможность сохранять через batch больше 100 объектов одновременно.

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

Доработать этот класс, чтобы можно было конфигурировать при необходимости batchHandler.
Пример его настройки

 var batchHandler = new DataObjectODataBatchHandler(dataService, httpServer, isSyncBatchUpdate);
            batchHandler.MessageQuotas.MaxPartsPerBatch = 1000;
            ODataRoute route = config.MapODataServiceRoute(routeName, routePrefix, model, pathHandler, routingConventions, batchHandler);

При использовании timeless-date формируется некорректный SQL-запрос.

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

При использовании в backend'е библиотеки ODataService из ветки develop-v6.2
падает тест "CRUD | odata-reading | data types: reading | data types" из состава тестов ember-flexberry-data.

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

Успешное прохождение тестов.

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

Настроить и запустить тестовый модуль "CRUD | odata-reading | data types" ember-flexberry-data c использованием backend'а на основе ODataService ветки develop-v6.2.

Пути решения

Падение происходит в блоке с комментарием "Timeless date as String with some format* из-за неверно сформированного SQL-запроса. Сравнение lcs, передаваемой в ORM, по текстовому представлению для версий ODataService develop-v5.1 и develop-v6.2 не дало каких-либо отличий. При этом тексты SQL-запросов, отправляемые на сервер БД, отличаются. Исходя из этого есть подозрение, что проблема обусловлена работой версии ОРМ (6.0.*), используемой совместно с ODataService develop-v6.2 .

Проект на GitHub: https://github.com/Flexberry/NewPlatform.Flexberry.ORM.ODataService/blob/develop-v6.2/NewPlatform.Flexberry.ORM.ODataServiceCore/Controllers/DataObjectController.cs#L944
Ветка: develop-v6.2

Разработка примера приложения ODataService под Asp.Net Core 3

Цель

Разработать пример приложения ODataService под Asp.Net Core 3, аналогично примеру приложения под Asp.Net 4.6.1 (Samples/ODataServiceSample.AspNet ветки develop-v6.0).

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

Приложение должно инициализироваться для работы под управлением Web-сервера (т.е. не являться self-hosted).

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

Этап 1. Разобраться со способом инициализации OData 7.1.0 Core приложения под управлением Web-сервера.
Этап 2. Создать ветку feature-27-dotnetstandard-aspnet-core-sample. В указанной ветке создать решение и проект Samples/ODataServiceSample.AspNetCore . Реализовать заготовку приложения c использованием custom-библиотеки OData 7.1.0 Core (http://nuget.ics.perm.ru/packages/Microsoft.AspNet.OData-Debug/7.1.0-beta04), без подключения библиотеки ODataService (предполагаемые обращения к методам классов ODataService закомментировать).

Исходный код

Проект на GitHub: https://github.com/Flexberry/NewPlatform.Flexberry.ORM.ODataService
Ветка: feature-27-dotnetstandard-aspnet-core-sample

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

Тесты

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

https://github.com/Flexberry/NewPlatform.Flexberry.ORM.ODataService/tree/develop-v6.0/Samples/ODataServiceSample.AspNet

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

При запросе сущности с несуществующим ключом возникает исключение

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

При отправке одата-запроса вида /odata/<ObjectTypeName>(<not existing guid>) с бекенда возвращается ошибка 500 и исключение System.Runtime.Serialization.SerializationException: 'EdmEntityObject' cannot be serialized using the ODataMediaTypeFormatter.

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

Судя по спецификации протокола OData подобный запрос должен возвращать ошибку 404:

• OData/WebApi#50
• http://docs.oasis-open.org/odata/odata/v4.01/csprd04/part1-protocol/odata-v4.01-csprd04-part1-protocol.html#sec_RequestingIndividualEntities

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

Запросить из любой коллекции сущность с несуществующим идентификатором

Пути решения

В случае, если в результате запроса из БД не вернулось записей, возвращать ошибку 404. Проконтролировать, что ember-flexberry адекватно обработает данный ответ от сервера.

Исходный код

NewPlatform.Flexberry.ORM.ODataService/NewPlatform.Flexberry.ORM.ODataService/Controllers/DataObjectController.cs

Line 368 in 12df393

public HttpResponseMessage GetGuid()

Тесты

Реализовать тест, проверяющий возврат статуса 404 при запросе объекта по несуществующему ключу.

Добавить возможность определять свой метод формирования пути к файлу при скачивании файла

Цель

Добавить возможность определять свой метод формирования пути к файлу при скачивании WebFile.

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

На одном из проектов возникла необходимость изменить логику сохранения WebFile так, чтобы файлы на диске сохранялись в следующей структуре папок: Uploads/год/месяц/день/guid (год месяц и день сохранения файла).

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

Нужна возможность перед скачиванием файла передавать свою переменную в метод формирования пути (в нашем случае это дата сохранения файла, она будет храниться вне WebFile).

Проблемы с сохраненнием файла в gruoupedit

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

При сохранении объекта с детейлом файла падает batch запрос при попытке вычитать ещё не сохранённый файл.

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

Файл в детейле должен сохраняться без проблем.

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

1. Запустить локально стенд эмбер с бэкендом.
2. Подключить OdataService к бэкенду
3. Зайти на форму редактирования http://localhost:4200/ember-flexberry-dummy-suggestion-list
4. Добавить файл. Сохранить. => падение batch запроса

Пути решения

<Описание того, в чём заключается проблема>
<Подсказки программисту как исправить ошибку>

Исходный код

Проект на GitHub: https://github.com/Flexberry/ember-flexberry
Ветка: develop

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

batchUpdate возвращает данные до обработки их в BusinessServer

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

batchUpdate возвращает данные не обработанные в BS

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

batchUpdate должен возвращать данные после обработки в BS

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

1. Запустить приложение и бэкенд из приложенных архивов.
2. Изменить на эдитформе поля Class1.per2 и calss2.per, сохранить.
3. Поле Class1.per1 не изменилось (не отработало его изменение в BS), после обновления страницы изменение отобразилось.

Пути решения

Брать поля для возвращения resoponses из UpdateObject или Обновлять данные после batchUpdate

Исходный код

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

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

Документации по batchUpdate нет, возможно стоит добавить?

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

Product_59013.zip

РТЦ Тестирование и документирование\Примеры диаграмм для задач\Примеры ошибок в Caseberry\187885 Пример для проверки batchUpdate с обработкой в BS
187885 Пример для проверки batchUpdate с обработкой в BS.zip

g=posts&m=18862#post18862

Корректная обработка исключений в BusinessServer при batch-запросах в netstandard

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

В некоторых случаях не срабатывает событие отлова исключения на сервере, при срабатывании исключения в бизнес-сервере в batch-запросах.

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

При генерации исключения в бизнес-сервере информация об ошибке должна попадать в соответствующий обработчик ODataService.

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

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

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

.NET Framework?
mono?

Пути решения

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

Исходный код

Исправить в текущей версии

• 5.2.*,
• 6.0,
• 6.1.

Тесты

Реализовать тест на повторение, который будет использоваться для отлова регрессии.

При batch-запросе не сохраняется агрегатор, если после него обновляется детейл

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

При отправке batch-запроса если сначала обновляется агрегатор, а потом детейл, то изменённый агрегатор "перетирается" неизменённым при приходе детейла на редаетирование (можно отловить тут, когда приходит на обновление детейл: в объекте Request.Properties[DataObjectODataBatchHandler.DataObjectsToUpdatePropertyKey] агрегатор становится UnAltered и все изменения пропадают).

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

Изменения агрегатора не должны теряться.

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

1. Создать batch-запрос, в котором сначала обновляется агрегатор, затем - детейл.
2. Изменения в агрегаторе теряются.

Массовые SerializationException

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

В тестовой и продуктивной средах встречается масса ошибок SerializationException (в среднем 4 для тестовой среды и 20 для продуктива). У нас их ловит на бэкенде свой GlobalExceptionHandler.

Текст ошибки

System.Runtime.Serialization.SerializationException: 'EdmEntityObject' cannot be serialized using the ODataMediaTypeFormatter.
at System.Web.OData.Formatter.ODataMediaTypeFormatter.GetSerializer (System.Type type, System.Object value, Microsoft.OData.Edm.IEdmModel model, System.Web.OData.Formatter.Serialization.ODataSerializerProvider serializerProvider) [0x000ef] in <2e50d258365747bf8e23647205ede093>:0
at System.Web.OData.Formatter.ODataMediaTypeFormatter.WriteToStream (System.Type type, System.Object value, System.IO.Stream writeStream, System.Net.Http.HttpContent content, System.Net.Http.Headers.HttpContentHeaders contentHeaders) [0x00025] in <2e50d258365747bf8e23647205ede093>:0
at System.Web.OData.Formatter.ODataMediaTypeFormatter.WriteToStreamAsync (System.Type type, System.Object value, System.IO.Stream writeStream, System.Net.Http.HttpContent content, System.Net.TransportContext transportContext, System.Threading.CancellationToken cancellationToken) [0x00059] in <2e50d258365747bf8e23647205ede093>:0
--- End of stack trace from previous location where exception was thrown ---

at System.Web.Http.WebHost.HttpControllerHandler.WriteBufferedResponseContentAsync (System.Web.HttpContextBase httpContextBase, System.Net.Http.HttpRequestMessage request, System.Net.Http.HttpResponseMessage response, System.Web.Http.ExceptionHandling.IExceptionLogger exceptionLogger, System.Web.Http.ExceptionHandling.IExceptionHandler exceptionHandler, System.Threading.CancellationToken cancellationToken) [0x000ae] in :0

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

Абсолютно непонятно, как повторить и кто создаёт некорректный payload для сериализации.

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

Локально: Windows, .net 461, IIS 10 Express
Удалённо: Linux, mono 5.18.0, docker (flexberry/alt.p8-apache2-mono:5.18.0)

Пути решения

Требуется расширенный дебаг.

Исходный код

Исключение прилетает из этого метода:
https://github.com/OData/WebApi/blob/v5.7.0/OData/src/System.Web.OData/OData/Formatter/ODataMediaTypeFormatter.cs#L622
Предлагаю добавить дополнительное логирование в:
https://github.com/Flexberry/NewPlatform.Flexberry.ORM.ODataService/blob/develop/NewPlatform.Flexberry.ORM.ODataService/Formatter/CustomODataSerializerProvider.cs

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

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

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

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

Не должно падать.

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

Отправить на бэк запрос, где в фильтре есть цепочка мастеров, но промежуточных мастеров нет ни в фильтре, ни в представлении.

Пути решения

В ходе обработки запроса вызывается функция LinqToLcs.GetLcs, которая падает из-за отсутствия в представлении промежуточных мастеров.
Надо или добавлять в представление все промежуточные мастера автоматически, или поправить функцию GetLcs чтобы она от такого не умирала.

Быстрая выгрузка данных для Excel Export

Цель

Реализовать более быстрое получение и формирование данных для Excel Export Service

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

Сделать получение данных в виде ObjectStringDataView, используя метод .LoadStringedObjectView

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

Отказаться от использования UnityFactory в ODataService

Цель

Заменить UnityFactory на более "здоровые" способы разрешения зависимостей.

Проблема с сохранением 2-х детейлов разных типов в одном batchUpdate

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

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

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

Оба детейла должны корректно обновиться.

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

Реализовать тест в котором для соответствующей структуры будет выполняться batchUpdate.

Пути решения

Разобраться почему перечитывается объект, который имеет статус Altered.

Исходный код

Реализовать исправление для v5.2, потом перенести в 6.0.

Тесты

Начать с разработки теста.

Поддержать .NET Standard 2.0

Цель

Требуется реализовать поддержку .NET Standard 2.0 с целью использования одного набора исходных кодов для исполнения в .NET Framework 4.6.1 и .NET Core 2.

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

1. Реализовать поддержку .NET Standard 2.0, включая все проекты, от которых зависит ODataService.
2. Проверить, что всё работает

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

Требуется оставить совместимость на уровне публичных методов, чтобы прикладные проекты могли пересобрать свои решения без лишних сложностей.
Черновая реализация была выполнена для .NET Core 2, нужно свести изменения из текущей версии и реализовать в формате .NET Standard 2.0.
В результате должен быть выпущен NuGet-пакет версии 6.

Исходный код

• Используется данный репозиторий.
• Черновая реализация поддержки .NET Core 2 выполнена в ветке feature-dotnetcore2 нужно смотреть в неё и брать те изменения, которые позволят собирать решение под .NET Standard 2.0.
• Разработку вести в ветке feature-27-dotnetstandard. Там уже установлен ORM, собранный под .NET Standard 2.0.

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

• Ссылка

Тесты

Тесты должны проходить.

Необходимость count в запросе к Odata

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

Запрос к odata не возвращает никаких данных, если не указать count=true
Пример:
http://localhost:8085/map/odata/NewPlatformFlexberryGISMaps?%24count=true - дает ожидаемые результаты
http://localhost:8085/map/odata/NewPlatformFlexberryGISMaps? - дает пустой результат:

{
"@odata.context": "http://localhost/map/odata/$metadata#NewPlatformFlexberryGISMaps",
"value": []
}

То же самое с остальными типами, с указанием фильтра/select/expand

Версия OdataService - 6.1.0-beta13

В метаданных odata публикуется коллекция DataObjects

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

В приложении, в котором одата настроена с помощью DefaultDataObjectEdmModelBuilder, публикуется коллекция DataObjects, или ICSSoftSTORMNETDataObjects в зависимости от переданных параметров. При попытке вычитать записи коллекции /odata/DataObjects возникает ошибка

{"error": { "code": "500", "message": "Object reference not set to an instance of an object", "details": [], "innererror": {"trace": [{"message": "Object reference not set to an instance of an object", "stack": "  at NewPlatform.Flexberry.ORM.ODataService.Model.DataObjectEdmModel.GetDataObjectDefaultView (System.Type dataObjectType) [0x0002a] in <cf6fd649e977427b8981e1721c465c51>:0 
  at NewPlatform.Flexberry.ORM.ODataService.Controllers.DataObjectController.CreateLcs () [0x00042] in <cf6fd649e977427b8981e1721c465c51>:0 
 at NewPlatform.Flexberry.ORM.ODataService.Controllers.DataObjectController.ExecuteExpression () [0x0000c] in <cf6fd649e977427b8981e1721c465c51>:0 
  at NewPlatform.Flexberry.ORM.ODataService.Controllers.DataObjectController.Get () [0x00006] in <cf6fd649e977427b8981e1721c465c51>:0 "}]}}}

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

Не публиковать коллекцию DataObjects в метаданных odata.

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

1. Настроить odata с помощью DefaultDataObjectEdmModelBuilder
2. Вызвать /odata, убедиться, что в публикуемых метаданных есть коллекция DataObjects
3. Попытаться запросить коллекцию DataObjects

Пути решения

В методе Build исключить тип DataObject из публикуемых типов/

Исходный код

https://github.com/Flexberry/NewPlatform.Flexberry.ORM.ODataService/blob/develop-v6.1/NewPlatform.Flexberry.ORM.ODataService/Model/DefaultDataObjectEdmModelBuilder.cs