На днях провел небольшую экскурсию в свое прошлое и подвел итоги.
Вкратце.
1. Общий объем исходных кодов рабочих проектов, с которыми приходится регулярно иметь дело, составляет около 80MB.
2. Половину составляют тесты.
А я еще чертыхаюсь — что так все стало сложно и тяжко? 🙂
Вчера весь день доводил до ума одну конструкцию IBProvider, которая была сделана одной из первых в его третьей версии. И краем глаза увидел код вида:
:inherited(NULL)
,m_ProviderClassID(ProviderClassID)
,m_spData(pData)
,m_spUnkOwner(pUnkOwner)
{
assert(m_spData);
assert(m_spUnkOwner);
Непорядок, подумал я. Надо бы задействовать structure::not_null_ptr для подсказки смарт-указателям:
,m_spData(structure::not_null_ptr(pData)) ,m_spUnkOwner(structure::not_null_ptr(pUnkOwner))
Но решил не отвлекаться.
К вечеру, а тем более сегодня с утра, уже не мог вспомнить — ГДЕ ЭТО Я ВИДЕЛ???
Чертыхаясь, пришлось осваивать регулярные выражения.
С использованием справок, онлайн-тестеров и такой-то матери, осилил выражение — (,m_sp)[\w]*[(][p].
Нашлось даже больше чем ожидал:
I am an engineer a regular expression expert! 🙂
Почему компания «Интел» делает ставку в разработке чипов на гений Джима Келлера?
Их отличительной чертой станет разделение основных функций, что позволит компании улучшать будущие микропроцессоры по блокам.
Надо бы где-то сохранить нюансы связанные с SSIS, remote MSSQL, OLE DB и транзакциями.
1. Настроить DTC на обоих компьютерах.
Control Panel\All Control Panel Items\Administrative Tools\Component Services
Обращаем внимание на «No Authentication Required».
2. В FireWall на обоих компьютерах нужно разрешить DTC.
—
Наверное, в диких условиях так делать нельзя.
Но для тестовой инфраструктуры, когда нужно быстро разобраться с проблемой ленивого пользователя IBProvider — самое оно.
Выложил новое обновление .NET провайдера, в котором реализован workaround костыль для костыля в SSIS — v1.20.
Так что теперь SSIS может закачивать данные в FB/IB через lcpi.data.oledb->IBProvider.
Есть три вещи, в которых я провожу 90% времени во время создания кода (порядок произвольный):
1. Visual Studio 2019 CE
2. WinCVS
3. Araxis Merge Pro
Первые две вещи — бесплатные.
Araxis куплен и лицензия многократно продлена.
Если вы пользуетесь этой штукой, то каждый раз, когда нажимаете на кнопочку «закрыть» на вкладке с сравнением файлов, можете мысленно вспоминать меня (ага). Это я их задолбал и они её добавили.
В последнем обновлении появилась еще одна «мегафича» — подсветка фрагментов текста, идентичных выделенному блоку.
Я их наверное лет шесть слезно просил добавить эту штуку.
Теперь вот в некотором замешательстве, потому что новых идей по улучшению этого инструмента у меня нет 🙂
Привет всем.
Никак не получается притормозить изменения в IBP и перейти к финализации версии 5.17. Ну очень увлекательное занятие.
0. Сначала о стороннем. Судя по субъективным наблюдениям — если гонять тесты в четыре потока, то FB3 (Win/SS/x64) вроде как работает без проблем. Если в десять потоков, то рано или поздно к нему приходит северный пушистый зверь и его приходится перегружать.
HOME4 Wed May 13 09:39:53 2020
Database: D:\DATABASE\RAM\IBP_TEST_FB30_D3.GDB
internal Firebird consistency check (pointer page vanished from DPM_next (249), file: dpm.cpp line: 1904)
При Обаме такого не было.
1. В IBP добавлена поддержка InterBase 2020 (v14). Поддержка заключается в определении нового списка ключевых слов и подключении исправленного механизма чтения/записи массивов. Последнее, по большому счету, заключается в прогоне тестов для 32-битного и 64-битного сервера.
Впечатление о сервере абсолютно нейтральное. Даже вспоминаться его родителей не хочется. Не упал и … ладно. Запросы типа «select EXTRACT(DAY FROM NULL) FROM …» как не переваривались, так и не перевариваются.
2. В схеме метаданных PROCEDURES корректно восстанавливается определение UDR процедур Firebird. Тут уже можно и выругаться по поводу отсутствия в дистрибутиве FB3 откомпилированного модуля udrcpp_example.dll. Типа, сами разбирайтесь …
(далее…)
В новой тестовой сборке IBProvider (v5.17.0.34920) осуществлен переезд на 64-битные unsigned счетчики ссылок COM-объектов.
Как в 64-битных, так и в 32-битных сборках.
IUnknown::AddRef теперь всегда возвращает 1, а IUnknown::Release или 1 или 0.
—
Внутренние объекты тоже переведены на 64-битные счетчики ссылок.
—
Для инкремента и декремента используются Interlocked-функции Win32 API.
На древней 32-битной WinXP SP2 (в виртуальной машине) все работает.
Полагаю, проблемы будут только на древних системах с 32-битными процессорами.
Надо сформулировать, в первую очередь для себя, базовые принципы, на которые стоит опереться при создании интерфейса компонент. Пока нахожусь в здравом уме и ясной памяти 🙂
1. В основе должен быть IUnknown.
— Это динамическая поддержка нескольких интерфейсов
— Это агрегация
1.5 Взять из COM принципы управления памятью и указателями на интерфейсы.
2. Первый аргумент методов должен быть указатель на интерфейс контекста вызова. Через этот контекст можно:
— Выполнять отмену вызова
— Возвращать описания ошибок/предупреждений/сообщений вызова
— Выделять память компоненту
Нужно ли передавать контекст в методы контекста? Наверное, да.
<уже начал напрягаться, чтобы вспомнить>
3. Для настройки и получения характеристик компонент следует использовать свойства, сгруппированные в наборы.
— Для идентификатора набора свойств вполне подходит GUID.
— Внутри набора используется целочисленный идентификатор свойства.
— У компоненты может быть несколько наборов свойств.
— У свойства может быть несколько равнозначных символьных идентификаторов.
— Свойство может связанно с несколькими объектами внутри компоненты (например — Columns внутри Rowset). При получении/установки свойства нужно указывать идентификатор целевого объекта.
4. Нужен аналог VARIANT. Для универсальной передачи типизированных значений (свойств, в первую очередь).
<пока все>
—
А, ну да. Напомню себе, что у модуля с компонентами должен быть метод инициализации и деинициализации. Допускается повторная инициализация, компенсируемая связанным вызовом метода деинициализации.
—
PS. Если вспомню что еще, дополню.
В заканчивающимся апреле в IBProvider произошла пара сдвигов, которые планировались очень давно, но до них все никак «не доходили руки».
1. Получение плана запроса. Летом 2019-го один коварный клиент убедительно попросил добавить возможность получать через провайдер план запроса.
Я об этом думал уже давно. А тут еще и совесть начала про это напоминать. В общем, добавил.
Отмечу, что, благодаря этой небольшой задаче, завершена сборка новой пазлы для управления OLE DB свойствами — главой штуки пятой версии IBProvider.
2. Переезд на nullptr. Лет 10 назад, при переезде на VS2010, в библиотеку на C++ был добавлен псевдоним nullptr — structure::null_ptr. Он был нужен для обратной совместимости с VS2008.
С VS2008 я завязал достаточно давно. От VS2010 (и VS2012) я отказался год назад. С начала года, прекращена поддержка VS2013, VS2015. А structure::null_ptr продолжал жить и использоваться.
На прошедших выходных, собрав волю в кулак, я его изничтожил.
Так что, как сказано в одной популярной фильме — «Граждане, обратно дороги нет!»
—
Вообще, изменений, как обычно, прет очень много. Этот процесс напоминает покраску корабля, которая, как говорят сведущие люди, никогда не заканчивается…