Надо сформулировать, в первую очередь для себя, базовые принципы, на которые стоит опереться при создании интерфейса компонент. Пока нахожусь в здравом уме и ясной памяти 🙂
1. В основе должен быть IUnknown.
— Это динамическая поддержка нескольких интерфейсов
— Это агрегация
1.5 Взять из COM принципы управления памятью и указателями на интерфейсы.
2. Первый аргумент методов должен быть указатель на интерфейс контекста вызова. Через этот контекст можно:
— Выполнять отмену вызова
— Возвращать описания ошибок/предупреждений/сообщений вызова
— Выделять память компоненту
Нужно ли передавать контекст в методы контекста? Наверное, да.
<уже начал напрягаться, чтобы вспомнить>
3. Для настройки и получения характеристик компонент следует использовать свойства, сгруппированные в наборы.
— Для идентификатора набора свойств вполне подходит GUID.
— Внутри набора используется целочисленный идентификатор свойства.
— У компоненты может быть несколько наборов свойств.
— У свойства может быть несколько равнозначных символьных идентификаторов.
— Свойство может связанно с несколькими объектами внутри компоненты (например — Columns внутри Rowset). При получении/установки свойства нужно указывать идентификатор целевого объекта.
4. Нужен аналог VARIANT. Для универсальной передачи типизированных значений (свойств, в первую очередь).
<пока все>
—
А, ну да. Напомню себе, что у модуля с компонентами должен быть метод инициализации и деинициализации. Допускается повторная инициализация, компенсируемая связанным вызовом метода деинициализации.
В заканчивающимся апреле в 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 аутентификация.
