Привет всем.
На сайт выгружен новый триал IBProvider v3.28 с собственным механизмом чтения/записи массивов базы данных. Как я тут уже ранее писал — все это затеяно ради исправления бага с VARCHAR-массивами. Вкратце — клиент вместо VARCHAR-массивов должен был работать с CSTRING-массивами.
Исправление доступно только для серверов (FB/IB/YA), работающих на Windows (winnt_x86, winnt_amd64). Для остальных операционных систем и процессоров будет задействован старый добрый ISC API с одним ограничением — без поддержки чтения/записи VARCHAR-массивов.
Если есть пожелание добавить другие платформы — напишите, добавлю. Здесь только одна проблема — нужно будет прогнать тесты.
Настройка
По умолчанию, провайдер сам выбирает подходящий режим чтения/записи массивов с учетом платформы сервера и ODS базы данных.
Процессом выбора можно порулить с помощью нового свойства инициализации — «array_rw_mode». Допустимые значения: «api» или «direct».
Настройка распространяется на все колонки с массивами. Выборочная настройка для отдельных колонок не доступна.
Отмечу, что в случае IB7.1+ новый механизм нужно включать явно. По умолчанию, провайдер будет работать через ISC API. Это связано с шифрованием содержимого колонок, которое IBProvider, понятное дело, обеспечить не может.
Для FB (на Windows, x86/amd64), по умолчанию, будет использоваться новый механизм.
Это точно работает правильно?
Собственный механизм чтения/записи массивов был проверен практически на всех выпущенных версиях FB/IB. В том числе и с помощью перекрестных проверок.
Немного о внутренностях
Массивы в базе данных хранятся в блобах. Так что, новый механизм — это код, напрямую работающий с этими блобами.
Счастье наступило?
Лично для меня — да.
А в целом — нет. Потому что gbak работает через ISC API и, соответственно, он не сможет правильно сохранить и восстановить VARCHAR-массивы. Но это уже другая история.
By fact, it is BREAKING NEWS!
Adriano читает firebirdnews.org
PS. По моему, это как раз тот случай, когда надо сначала перепрыгнуть…
Привет Типа утро доброе.
Подошел Приполз утром к компьютеру.
И слышу характерное «плям!».
Напрягся.
[16.02.2016 23:01:19] [info] Provider DLL :_IBProvider_v3_vc14xp_w64_d.dll
[16.02.2016 23:01:19] [info] Provider Version:3.27.3.20014
[16.02.2016 23:01:19] [info] Server Name :Firebird
[16.02.2016 23:01:19] [info] Server Version :3.0.0.32332
[16.02.2016 23:01:19] [info] Client Name :Firebird
[16.02.2016 23:01:19] [info] Client Version :3.0.0.32332
[16.02.2016 23:01:19] [info] Database ODS :12.0
[16.02.2016 23:01:19] [info] Database Dialect:3
....
[17.02.2016 07:11:03] [Thread #2] [START ] rowset.asynch.003.cancel_active_loader.read_only.random_access_v1.non_blocking_fetch.fetch_first_row.reexec_1 [#120]
Assertion (statement->haveException() == 0) failure: ..\..\..\src\remote\client\interface.cpp 2278
Привет всем.
Случайно обнаружил следующую вещь в исходниках Firebird:
firebird\branches\B2_0_Release\src\jrd\inf_pub.h:
isc_info_db_impl_sun_amd64 = 71, //появился в FB2.0.5
firebird\branches\B2_1_Release\src\jrd\inf_pub.h:
isc_info_db_impl_linux_mipsel = 71, //появился в FB2.1.0
isc_info_db_impl_sun_amd64 = 74, //появился в FB2.1.1
Вздрогнул и полез проверять стабильность идентификаторов в рамках пакетов исправлений.
Привет всем.
В Firebird 2.0 был исправлен алгоритм вычисления размера буфера (XSQLVAR::sqllen) текстовых колонок (CHAR/VARCHAR) — он начал учитывать кодовую страницу подключения. Спасибо Adriano dos Santos Fernandes.
Здесь были чертыхания по поводу кодовой страницы блоба и XSQLVAR::sqlscale
До этого (а в InterBase до сих пор), размер буфера под значение вычислялся как количество символов в столбце умноженное на максимальное количество байт в одном символе кодовой страницы столбца.
Проблема, к примеру, проявляется при попытках прочитать столбца с кодовой страницей WIN1251 в подключении с кодовой страницей UTF8. Вылазит ошибка «Arithmetic exception, numeric overflow, or string truncation».
Я как-то пробовал подсовывать серверу правильно вычисленное значение буфера в XSQLVAR::sqllen, но он там внутри у себя все равно использовал буфер с неправильным размером.
Но недавно появилась мысль — а если попробовать работать не с XSQLDA, а непосредственно с MSG-буфером, где появляется возможность использования таких волшебных типов BLR-типов данных как varying2 и text2, для которых можно указать кодовую страницу?
Если сервер сможет вернуть клиенту текстовые данные без приведения к кодовой странице подключения, то это автоматически решит обозначенную проблему с переполнением буфера. Привести текстовые данные к кодовой странице подключения я могу и сам.
Во какая мысль.
Пожалуй, я её попробую покопать поглубже сразу после того как допилю новый код для работы массивами.
UPD1.
Мысль, наверное, не совсем правильная. Нужно сначала попробовать varying2/text2 с указанием кодовой страницы подключения и правильного размера буфера под данные. Может прокатит.
Привет всем.
Асилил. На этом будем считать, что марафон с v3.27 завершен.
Сейчас надо собирать мозги в кучу и допиливать исправление для CORE-1588.
Потом нас ждут другие, по настоящему интересные задачи.
Привет всем.
В последнее время утомляется чтение как художественной так и технической литературы. Особенно когда рядом есть рабочий компьютер (в смысле, компьютер на котором я работаю). Появляется мысль «Н@#&р, лучше пойти повозиться с кодом. Любым». У меня его на любой вкус и цвет уже — навалом.
Так что прочитанной статье можно сказать повезло.
1. Я сегодня достаточно удолбался выполнять роль отца семейства, чтобы оставить надежду вечером повозиться «со своей прелестью» хотя бы пару часов.
2. На компьютерах работают тесты, которые жалко не то чтобы прерывать, а даже приостанавливать.
Первая часть.
Вторая часть.
Лет двадцать назад я бы даже и не понял о чем в ней написано.
А сейчас («сидя в уютном доме, в приличном районе») могу сказать, что моя семья сделала правильные инвестиции.
—-
Впрочем, лично меня сейчас гораздо больше забавляет то, как моя гора кода, созданная за последнее десятилетие, достаточно без проблем эволюционирует и приспосабливается к моим безбашенным идеям 🙂
—-
UPD. Клиенты, надеюсь уверен, тоже неплохо вложились…
Привет всем.
На днях провел эксперименты, проверяющие работоспособность внешнего исправления для ошибки сервера (FB/IB) — CORE-1588.
Краткое описание ошибки — сервер получает и возвращает VARCHAR-массивы как CSTRING-массивы.
К счастью, этот баг имеет ограниченную область действия — в базу, в конечном итоге, пишутся VARCHAR-массивы. Это можно проверить поэлементным чтением VARCHAR-массивов.
Решение, как и было предположено ранее, заключается в самостоятельном формировании блоба массива.
Извращение, конечно. Хотя бы потому, что нужно учитывать тип процессора, на котором работает сервер базы данных. Эти сведения можно получить через информационное свойство «isc_info_implementation».
Самое приятное то, что в сервере предусмотрена лазейка для этого варварского внешнего формирования блоба с данными массива.
Будет интересно соорудить весь необходимый код и посмотреть на его работу.
Привет всем.
Собственно subj.
Последние несколько недель я размышлял над всем этим процессом и сейчас можно подвести некоторые итоги.
От начала до конца — чуть больше года. Эффективный объем времени, совпадает с начальным прогнозом — 6 месяцев. Остальное время съели релиз ADO.NET провайдера, перевод сайта на WordPress (грустно вздохнул) и другие процессы реальной жизни.
Немножко ошибся с оценкой объема исходного кода подсистемы. Думал уложиться в 800KB. Получилось 1.7MB. Учту на будущее. Впрочем, я думал что код будет компактным, но сложным. А он оказался (в конечном итоге) прямолинейным и объемным.
Объем исходных текстов модульных тестов — 3.7MB. Соотношение 1:2, в последнее время, стало нормой. Всего генерируется 24K тестов. Основной «мультипликатор» — 4 режима протокола соединения (rpc, batch_send, out_of_band, lazy_send).
32-х битная DLL провайдера увеличилась где-то на 670 килобайт. Это больше чем «весит» fbclient.dll. 200KB сожрали ресурсы с шаблонами сообщений серверных ошибок (английский и русский).
Нагрузочное тестирование показывает, что IBProvider при работе через встроенного клиента поедает на 5% процентов процессорного времени меньше, чем через fbclient.dll. А реальное время работы — вообще не поменялось. В целом, здесь сложно ожидать чуда. Код стал немного «умнее», но увеличилось количество проверок. Все, что приезжает из сети, теперь проверяется самым тщательным образом.
(далее…)
Привет всем.
Похоже, 27-е обновление вышло на финишную прямую. И с сайта IBProvider можно загрузить сборку 19276, которая (очень надеюсь) будет релизной.
Основным изменением является добавление поддержки соединения с FB0.9, FB1.0, FB1.5, FB2.0 и FB2.1 без использования fbclient.dll. Это 10-ый и 11-ый протоколы.
