Привет всем.
Завершается девятый месяц с момента рестарта проекта провайдера для EFCore. Сейчас специально посмотрел срок беременности у слонов — 22 месяца. Думаю, в нашем случае процесс продлится не так долго.
Текущее состояние
1. В связи с переездом EFCore на .NET6, пришлось немного откатиться назад, чтобы прикрутить поддержку новых типов данных DateOnly и TimeOnly.
С одной стороны хочется выругаться, а с другой — этот локальный рестарт улучшил код как самого провайдера так и его тестов.
Процесс прикручивания пока не завершен, но базовая поддержка (чтение, запись, операторы сравнения) уже реализована. Осталось окучить трансляцию методов этих типов. Ничего сложного, но требуется время.
(далее…)
Проехал еще один, восьмой месяц разработки новой игрушки — провайдера для EFCore.
Как и планировалось ожидалось, за этот месяц удалось довести до ума всё ранее созданное.
Начинал с ненапряжных 3 тысяч тестов, а сейчас десятиядерный процессор лежит плашмя, компилируя эти тесты. На сборку уходит больше 5 минут. HT если и греет, то слабо.
В целом, ближайшая цель — окучить новую группу тестов GearsOfWar спецификации EFCore. Работы в этом направлении уже начаты пару месяцев назад.
Стоит признать — эти тесты уже реально улучшили качество проекта.
Привет всем.
Проехало семь месяцев процесса создания провайдера для EFCore.
Забавно, но похоже я только в этом месяце разгребу ранее созданные наработки по этому направлению.
Прошло чуть больше 6 месяцев с начала рестарта проекта для EFCore 🙂
Пока полет нормальный. Даже вроде нашел компромис для сохранения поддержки первого диалекта, хотя было желание от неё избавиться… Без этого извращения дополнительного груза, код определенно будет хуже в плане структурированности.
В этом месяца, без фанатизма, пилил очередную подсистему провайдера для EFcore — локальные варианты серверных арифметических операций. Сложение, вычитание, умножение и деление. Третий и первый диалекты.
Вроде все получалось и неделю назад, даже, появилось ложное ощущение что «пронесёт» и все получится 🙂
Не пронесло.
Вчера добрался до последнего этапа этой стадии (или наоборот, не суть) — деление для первого диалекта.
И (снова) нарвался на мину фундаментальные ограничения базовой технологии, лежащей в основе всего этого поделия — LINQ.
- Компилятор может самостоятельно выполнить часть работы с константами (преобразовать тип, выполнить арифметическию операцию) и передать результат работы в LINQ.
- В LINQ не передается информация о явном и неявном конвертировании.
Но обо все попорядку. Попробую описать проблему как можно короче. (далее…)
Позавчера посетил семинар по возможностям InterBase. Для расширения кругозора и все такое.
Особо не скучал.
По всей видимости рассказывали про
- Change View
- Шифрование
То есть про вещи 5 и 10 летней давности. Поправьте меня, если я ошибаюсь.
Change View, когда он появился, меня немного зацепил и я даже начал думать как его прикрутить к IBProvider. Как обычно, сразу наступил на грабли. А потом понял, что они этой хренью сломали АПИ. Ну и … с ними. Бестолочи.
В конце рассказали про future.
Обещают новые ADO.NET провайдеры (почему-то во множественном лице) и интеграцию с Visual Studio. Реально заинтреговали.
До упора не досидел и ушел — устал.
Потом долго думал про стюардессу и технологический предел каждой цивилизации.
Процесс разработки провайдера для EFCore потихоньку движется вперед.
Протоптал одну из самых мутных частей реализации.
Едем дальше.
UPD. Чтобы два раза не вставать, хочу сказать СПАСИБО всем, кто не ждёт 🙂
В связи с текущей возней с EFCore пришлось «освежить» понимание множества базовых вещей.
Одна из этих вещей — вещественные числа.
Задача
1. Добавляем запись с FLOAT колонкой.
2. Выбираем эту запись и сравниваем значение FLOAT колонки с ожидаемым значением. Ожидаемое float-значение передается в запросе в виде текста.
Выглядит это как-то так:
const string c_valueSource="-3.40282347E+38";
const float c_valueTarget=float.MinValue; //-3.40282347E+38
System.Int64? testID=Helper__InsertRow(db,c_valueSource,c_valueTarget);
var recs=db.testTable.Where(r => (float)(object)c_valueSource==r.COL_TARGET && r.TEST_ID==testID);
В конечном итоге, на сервер уезжает запрос вида:
SELECT "t"."TEST_ID", "t"."COL_VARCHAR_128", "t"."COL2_FLOAT"
FROM "TEST_MODIFY_ROW2" AS "t"
WHERE (-3.40282347E+38 = "t"."COL2_FLOAT") AND ("t"."TEST_ID" = CAST(:__testID_0 AS BIGINT))
То есть, вроде все путем. Но сервер возвращает 0 записей.
Почему, Карл? (далее…)
Обнаружил на хабре статью
… Были запуски под много чем от MySQL до покойного, наверное, Firebird …
USUS (c) моё.
PS. Статью прочитал. Да, тяжко…
Привет всем.
Открыл для себя, что в FB3 пара запросов:
select cast('1.5' as integer) from dual
select cast(cast('1.5' as numeric(3,1)) as integer) from dual
возвращает двойку.
Точнее, про второй я как бы это знал и учитывал. А вот про первый нет …
Если мне не изменяет память, лет пятнадцать (а то и больше) вместо округления было обрезание.
IBProvider в первом случае округляет и, помню, мне говорили что я пру против сервера …
—
В общем, меня это настолько удивило, что я проверил на IB5.6.
Фух, память мне не изменяет.
«cast(‘1.5’ as integer)» возвращает 1.
«cast(cast(‘1.5’ as numeric(3,1)) as integer)» возвращает 2.
PS. Вот жеж …
