Привет всем.
1. Обладатели лицензий могут скачать из личного кабинета очередной релиз IBProvider — v3.25.1.18333.
2. Начиная с прошлого четверга начато постепенное тестирование работы IBProvider-a через нового клиента. На текущий момент устранены выявленные огрехи (тестам и ассертам — СЛАВА!). Сегодня ночью проехал достаточно агрессивный набор нагрузочных тестов, проверяющий работу с результирующими множествами. Ошибки были очень интеллигентные. Типа:
1. [LCPI.IBProvider.3]: [winsock] Сбой записи данных в порт подключения. Ошибка WinSock: 10054.
2. [LCPI.IBProvider.3]: Ошибка подтверждения транзакции. Транзакция будет отменена.
3. [LCPI.IBProvider.3]: [Подсистема: remote_fb.inet] Запись в порт невозможна. Предыдущая операция записи завершилась с ошибками.
4. [LCPI.IBProvider.3]: Ошибка отката транзакции.
Что там случилось — я не знаю. В следующий раз оставлю сервер (2.5.5.26942) под отладчиком.
3. Пока не утвержден, но сформулирован следующий план выпуска IBProvider:
— Недели через две будет выпущена версия 3.26, в которую попадут все исправления сделанные в рамках интеграции нового клиента.
— Постараемся одновременно с 3.26 выложить триал 3.27 с новым клиентом.
— Две-три недели будет идти нагрузочное и прочее тестирование. Потому что реально страшно 🙂
— Потом будет релиз 3.27 с новым клиентом.
То есть, при даже благополучном стечении обстоятельств, финиш будет не раньше 20-ых чисел декабря.
Привет всем.
На днях завершился процесс разработки низкоуровневого клиента для Firebird 2.5 (INET, все типы и режимы 12-го протокола). Так что на вопрос «асилю или нет?» ответ положительный.
В настоящий момент уже начался процесс интеграции с основным кодом IBProvider-a. Уже даже входит и выходит можно подключаться и отключаться.
Риск наткнуться на какую либо реально серьезную проблему — минимален. Сейчас основная сложность с придумыванием базовых названий для конструкций и файлов.
Лично я очень надеюсь, что в течении этой недели будут реализованы все необходимые переходники и можно будет начинать использовать основную тестовую систему IBProvider.
На самом нижнем уровне IBProvider и всех моих остальных, более менее крупных, проектов на С++ лежит единый базовый класс с парой методов — add_ref и release, управляющих счетчиком ссылок на объект.
Судя по истории репозитария (CVS), который был запущен 21 декабря 2000 года, этот класс появился раньше. Наверное, где-то в районе конца 99-го или начала 2000-го кода.
Забавно посмотреть на этапы эволюции этой конструкции, лежащей в основе всей архитектуры.
(далее…)
В качестве зарядки посмотрел выступление парня из Яндекса. Там половину времени занимает описание причин «почему не используются исключения». По мне — херня какая-та.
Но мысль появилась и я полез в исходники FB, посмотреть на один из моих любимых деструкторов:
Semaphore::~Semaphore()
{
if (hSemaphore && !CloseHandle(hSemaphore))
system_call_failed::raise("CloseHandle");
}
До сих пор не исправлен. Потому что:
Мы должны знать о системном сбое незамедлительно!
Всем привет.
Выложен новый триал OLE DB провайдера, в который внесены следующие исправления и изменения, связанные с массивами:
1. Исправлено формирование многомерных массивов. Внезапно обнаружилось, что IBProvider формирует описания размерностей не в том порядке. В результате сервер и провайдер по-разному вычисляют расположения элементов.
2. После очередного размышления над багой Firebird CORE-1588 (у InterBase аналогичная болезнь), пришел к выводу что на текущий момент самым правильным решением будет обрабатывать VARCHAR-массивы как CHAR-массивы. Это устранило костыли в коде IBProvider-а и принесло в мою душу гармонию и умиротворенность.
Чтобы два раза не вставать, похоже я нашел способ решения этой баги, но он достаточно тяжеловесный — нужно самостоятельно формировать и обрабатывать блоб с массивом. Возможно когда-нибудь запилю.
На уровне сервера эта проблема решается определением двух новых API-функций для записи и чтения массивов, которые будут правильно обрабатывать SDL-описание. Как выяснилось — в саму базу VARCHAR-массивы пишутся правильно. Надо будет, в качестве эксперимента, попробовать реализовать это в собственном клоне FB.
—
Вот такие вот дела. Все это побочный эффект реализации и тестирования сохранения массивов через собственный низкоуровневый INET-клиент для Firebird.
Релиз IBProvider-а (3.25) будет после реализации чтения массивов в этом низкоуровневом клиенте. Сегодня планирую начать тупить возиться в этом направлении.
Привет всем.
Чуть больше месяца назад поставил себе Visual Studio 2015 Community Edition и перевел на неё основные проекты: IBProvider, ADO.NET провайдер и тестовый проект собственного клиента к FB2.5 (в основном вожусь с ним). Ну и свой клон Firebird 2.5, тоже перевел. Не без спотыканий.
(далее…)
Dmitry Kovalenko on 11 сентября, 2015 | 1 Comment
Привет всем.
Пересобрал .Net провайдер под Framework 4.6. Дистрибутив можно скачать, как обычно, с сайта IBProvider и nuget.org. Полный список поддерживаемых версий FW выглядит так: 3.5, 4.0, 4.5, 4.5.1 и 4.6. В природе еще существует FW 4.5.2, но я решил его пропустить.
Естественно, помимо самого провайдера, собран и DDEX провайдер для Visual Studio 2015.
Dmitry Kovalenko on 6 августа, 2015 | 1 Comment
Решил добавить свежей воды в болото памяти под названием «Firebird и InterBase». В виде обновленного Free IBProvider, в который добавлена поддержка всех текущих версий FB/IB. В том числе для FB3 и IB XE7.
Сказано — сделано.
Медленно и печально продолжаю пилить собственную реализацию сетевого клиента к Firebird.
На днях реализовал выполнение запросов с IN-параметрами. Чертыхнулся, но сумел реализовать отправку пакета (op_execute) опираясь только на собственные данные пакета. В оригинале (fbclient.dll) при отправке этого пакета внезапно начинают лезть к объекту запроса. :facepalm: да и только.
Начал реализацию поддержки запросов с OUT-параметрами… Пока только начал. Но уже появилась мысль:
«Если меня вдруг угораздит проектировать подобные конструкции для обмена данными, то пакет будет включать информацию о своем размере. А еще лучше — размер будет находиться в самом начале пакета.»
Потому что глубинный смысл идеи «мы вот сейчас начнем отправлять пакет в порт подключения, а принимающая сторона сама должна определить момент когда он закончился» ускользает от меня. И в результате хочется ругаться.
Соорудил небольшой тест, сравнивающий производительность асинхронной и синхронной загрузки. Для разнообразия, в цикле выборки данных реализована модификация результирующего множества.
Конфигурация:
— Серверная машина: Q6600, 8GB, RAID0 из 4HDD, FB 2.5.4 SuperClassic
— Клиентская машина: Core i7, 16GB, SSD.
— Гигабитная сеть.
Тестировался 64-битный IBProvider.
Сразу озвучу результат — наблюдались устойчивые тридцать процентов ускорения работы.
(далее…)
