В заканчивающимся апреле в IBProvider произошла пара сдвигов, которые планировались очень давно, но до них все никак «не доходили руки».
1. Получение плана запроса. Летом 2019-го один коварный клиент убедительно попросил добавить возможность получать через провайдер план запроса.
Я об этом думал уже давно. А тут еще и совесть начала про это напоминать. В общем, добавил.
Отмечу, что, благодаря этой небольшой задаче, завершена сборка новой пазлы для управления OLE DB свойствами — главой штуки пятой версии IBProvider.
2. Переезд на nullptr. Лет 10 назад, при переезде на VS2010, в библиотеку на C++ был добавлен псевдоним nullptr — structure::null_ptr. Он был нужен для обратной совместимости с VS2008.
С VS2008 я завязал достаточно давно. От VS2010 (и VS2012) я отказался год назад. С начала года, прекращена поддержка VS2013, VS2015. А structure::null_ptr продолжал жить и использоваться.
На прошедших выходных, собрав волю в кулак, я его изничтожил.
Так что, как сказано в одной популярной фильме — «Граждане, обратно дороги нет!»
—
Вообще, изменений, как обычно, прет очень много. Этот процесс напоминает покраску корабля, которая, как говорят сведущие люди, никогда не заканчивается…
В одной популярной книге по программированию для домохозяек советуют каждый день что-нибудь выкидывать из вещей. Этот ценный совет применим и для сопровождения программных систем.
Решил выкинуть из IBProvider сомнительный метод чтения с I4-колонок с приведением NULL к нулевому значению.
Он используется, в том числе, для чтения значения колонок rdb$procedure_inputs и rdb$procedure_outputs (таблица rdb$procedures).
Хотя бы из кода, работающего с базами данных FB3.
Тем более, что запрос
select * from rdb$procedures x
where x.rdb$procedure_inputs is null or x.rdb$procedure_outputs is null
для тестовой базы данных FB3 возвращает пустое множество.
Для тестовой базы IB4.2 (решил копнуть в начале огорода) этот запрос возвращает непустое множество. NULL-ы есть как в INPUTS так и в OUTPUTS.
С тестовой базой FB2.5.9 — ситуация аналогична IB4.2.
А у FB3 (повторюсь) — все OK.
Задумался, улыбнулся, сделал бакап базы FB2.5.9 и отресторил её на FB3.
//Код из инсталлятора ADO.NET провайдера, который уже переехал на C++17.
template<typename... Args>
void BA_ErrorUtils::Throw__Error
(HRESULT const hr,
BA_Error_SrcID const srcID,
BA_Error_MsgID const errMsgCode,
Args&&... args)
{
assert(FAILED(hr));
BA_Error exc(hr,srcID,errMsgCode);
(exc<<...<<std::forward<Args>(args));
exc.raise();
}//Throw__Error
Но это все потом.
А пока — v5.14 это тот же v5.13.
—
Вышеобозначенные сборки (v5.14.0.33732) уже проехали через нагрузочное тестирование (которое сейчас работает как хорошо отрегулированный двигатель — без спотыканий).
Так что, думаю, на этой неделе они уйдут в релиз v5.14.
Обычно, нагрузочное тестирование IBProvider выполняется с использованием сборок, созданных компилятором последней Visual Studio. В настоящий момент времени это VS2019 (сигнатура сборок — vc16).
В личных кабинетах доступны еще сборки, собранные в VS2017.
На днях один очень старый и любимый клиент продлил лицензию. И выбрал сборки VS2017 (сигнатура vc15).
На сайт загружен обновленный инсталлятор ADO.NET провайдера, который самостоятельно может инсталлировать и деинсталлировать VSIX-пакеты с DDEX-провайдерами для VS2017/VS2019.
1. Есть объект со счетчиком ссылок (класс rem_port).
2. Этот объект управляется через смарт указатель. И, по идее, проблем быть не должно.
3. Тем не менее у него проблема с управлением времени жизни. Дважды удаляется в многопоточной среде.
4. Потому что конструктор rem_port, за каким-то …, вызывает addRef. И этот инкремент нужно где-то компенсировать однократным вызовом release.
Если я все правильно понял, багу заложили около 12 лет назад. Когда в rem_port добавили счетчик ссылок. Но это так, для ориентира.
Что делает этот патч. Он делает добавляет монопольность этого однократного вызова release.
Проблему давил OK-еем. Она не сильно мешала достижения финиша.
Позже сообразил, что она уже вылазила. Причем совсем недавно.
В том случае, проблема лечилась указанием имени пользователя в верхнем регистре (GAMER) — это (насколько я понимаю) задействовало SRP-аутентификацию. А с нижним регистром через раз отрабатывала Legacy_Auth аутентификация.
На сайт и в личные кабинеты загружены очередные обновления OLE DB и ADO.NET провайдеров.
IBProvider v5.12
В IBProvider, как я тут раньше писал, появилась поддержка колонок с автоинкрементом.
А если конкретнее, то во множестве с описанием колонок, получаемом через интерфейс IColumnsRowset, появилась колонка DBCOLUMN_ISAUTOINCREMENT с BOOL-значением. В ней будет True для колонок с автоинкрементом и False для всех остальных колонок.
Забавно, но в провайдер пришлось внести достаточно радикальные изменения, чтобы сделать «все по уму».
На финише, в IBProvider было внесено еще одно изменение — отображение ошибки Z_MEM_ERROR компрессора данных zlib1 на E_OUTOFMEMORY.
Основные сборки (vc16), как положено, прошли через многопоточное нагрузочное тестирование.
NetProvider v1.16
В OleDbDataReader, создаваемом с указанием CommandBehavior.SchemaOnly, разрешено использование методов Read, HasRows, RecordsAffected.
Предыдущие сборки провайдера запрещали такие вызовы и выкидывали исключение.
Клиент, в процессе переезда с System.Data.OleDb, обнаружил это лютое ограничение и попросил убрать его.
Другое
Доработаны и оптимизированы тесты. Причем для обоих провайдеров. Новые тестовые таблички (в которых по 4K колонок) дали всем прикурить.
Из личных кабинетов убраны сборки IBProvider v3. Все, эпоха закончилась.
