A.S. в проблемное место аппликухи воткнул локальную транзакцию - и invalid BLOB id действительно ушёл.

Т.е. теперь придется перекапывать это месторождение и разбираться, куда же на пол-пути делась правильная транзакция и что там вообще где происходит...

Симонов ДенисТебе прям точно нужен этот глючный dbExpress? Заменить его никак?

во всей аппликухе, которой больше 10 лет? малореально.

не говоря про необходимость тогда покупать новую библиотеку доступа (или новую Dlephi со всеми новыми библиотеками) в количестве нескольких штук, и... тирьям-пам-пам - находить и изучать новые баги и новые пути их обхода.

Симонов Денисс какого перепуга она на закладке dbExpress?

а хрен его знает, но если наведёшь на него мышку, увидишь, что он в пакете dcl-dbx-cds
CDS - это ClientDataSet, MIDAS, тот ещё мега-комбайн
а в SDS поверх CDS навернули ещё каких-то рюшек...

Ну, собственно говоря, главное что навернули - это навигацию по записям вперёд-назад, потому что у Firebird большинство запросов - однонаправленные. Видимо, это была основная цель, не перетаскивать в SQLQuery буферизацию из например TBDEDataSet, а просто сделать поверх.

Симонов ДенисAriochЗабавно, т.е. чтение BLOB выполняется как почему-то два BLR-запроса

не обязательно 2 может и больше. Сначала открытие блоба, а потом посегментное чтение. сегментов может быть больше чем 1.

Ещё забавнее, что чтение блобов было хотя и из ДРУГОЙ транзакции, но из ВЛОЖЕННОЙ (или параллельной), т.е. вообще говоря сами-то блобы должны были существовать, потому что создавшая их транзакция не закрывалась!

Т.е. тут похоже дело не в том, что временные блобы уничтожались, а в том, что к ним доступа не было!
Но поскольку такой ошибки не было предусмотрено - выдавалась Invalid BLOB id....

Возможно, для таких случаев стоило бы завести отдельный текст ошибки, чтобы сразу различать случаи "блоба нет вообще", и "блоб есть, но не для тебя". Раз уж блобы - больная тема с пониженнйо предсказуемостью...

Тут ещё ньюанс, что в dbx3/delphi2006 были параллельные транзакции, а dbx4/xe2 только вложенные в виде стека.... Т.е. с точки зрение "верхнего уровня" dbx - вторичные транзакции возможно должны были наследовать права доступа от родительской? хотя х.з. что там авторы dbx4 думали в этот момент.


Dimitry SibiryakovАффтар, проверил бы ты это поведение на четвёрке. Туда, кажется, приняли мой патч по
предотвращению преждевременного удаления блобов.

интересно, а как ты формулируешь "преждевременное" ?

поскольку reference counting надёжно протащить из FB engine аж в недра аппликухи, хрен знает на чём написанной, в общем виде нельзя - то тут выбор между Сциллой и Харибдой, откуда чаще прилетает.

Ну и да, проверить поведение - открой ссылочку на трекер и возьми готовый EXE, запусти и нажми кнопку
Таки проще, чем мне искать FB4, ставить его, разбираться как там пользователей создают и т.д.

Basil A. SidorovAriochа что при этом убивается когда-то присущая IB/FB предсказуемость и лёгкость в администрировании неподготовленными пользователями - так и постгресс с нейFB версий от 1.5 до 3.0 администрируется совершенно одинаково.
Да, админ может быть не в курсе каких-то фичей FB, ну так админу это и не требуется.

Смешно. Просто почитай в интернете кучу проблем, когда пользователи не могли создать SYSDBA или создавали, но не так, или не там и т.д.

Или когда вместо отдельного сервера внезапно запускается embedded, потому что в FB3/win теперь совсем не так, как в IB/FB0-1-2/Win

Basil A. SidorovДа, админ может быть не в курсе каких-то фичей FB, ну так админу это и не требуется.

ну и это, представь, что нужно "идиоту на телефоне" в техподдержке сделать исчерпывающее объяснение, как диагностировать и исправлять проблему с "идиотом на телефоне" от клиента.

Симонов Денис,

для этого мне нужно сочинять бронебойный метод перехода с FB2.1 с литералами кирилицей в PSQL, который будет работать всегда, а когда не будет - "идиоты на телефоне" у них и у нас смогут без меня это быстро порешать.

и при этом ещё недопустить ни у кого глюков из-за внезапного embedded (CORE-5004/CORE-5185)
а на демо-версии - ровно наоборот, гарантировать работу с файлом БД исключительно через embedded без установки standalone сервера и без неожиданных попыток соединиться через отдельный fbserver.exe

и ещё объяснить всем остальным, зачем я вообще эти проблемы создаю клиентам и нам самим

ради CORE-4641/CORE-5186 я бы даже попробовал, при прошлом начальстве особенно.
но и нынешнему я бы сходу привёл несколько случаев проблем клиентов, которые бы сразу исчезли. В основном типа "перенос на новый сервер"

вот лично с моей колокольни, лишние 50% производительности на терабайтной БД совершенно не имеют значения с беспроблемностью у пользователей класса "бабушка божий одуванчик"

Ariochне имеют значения с беспроблемностью

....сравнительно с беспроблемностью....

Симонов Денис,

потому что для каждого его проблемы - самые важные

потому что если не "плакаться" - то возникают упрёки "а что ж вы не напоминали" и "да кому вообще это нужно", от вас же самих на первой странице

так что я не плачусь, я напоминаю и разъясняю

hvlad- временный блоб с blob_id 1 в тр-ции A это совершенно не то же самое, что временный блоб с blob_id 1 в тр-ции B
- доступ к блобам тут не при чём

может быть лучше это было бы изменить, чтобы id временных блобов не пересекались?

именно потому, что они уходят наружу и там с ними аппликухи делают что хотят

ну и кроме того

Симонов Денисотдельная ошибка по поводу прав на чтение временного (и не только) блоба из другой транзакции недавно добавлена в 3.0.4.

как она могла быть добавлена, если у двух транзакций пересекающиеся значения хэндлов?

hvlad,

это не спасёт, но поможет их исправить

бывает API, подталкивающий к труднодиагностируемым ошибкам, а бывает API - подталкивающий к уменьшению количества ошибок, особенно сложных и непонятных. Хотя действительно что так, что так - это будет ошибки клиента API, что он не разобрался и не смог правильно реализовать.

и да, особенно "с точки зрения пользователя" - потому что даже если пользователь сможет надёжно воспроизвести (не всегда), не факт что возможна поездка разработчкиа к нему или передача всех данных от него.

навскидку, сделать отдельный "в памяти" генератор для temporary blob id или просто в temporary blob id в старших разрядах хэшировтаь transaction id - не сильно нагрузит сервер, зато поможет распознавать разные ошибки

Dimitry SibiryakovНу ок, давай в isc_blob_open() добавим ещё один параметр - транзакцию и задокументируем, что это должна быть та самая транзакция в которой получен blob id. Кому от этого станет лучше?

не надо, надо просто сделать чтобы ID временных блобов не пересекались между транзакциями с вероятностью 99,999% и это не трудно

лучше будет разработчикам софта под FB и пользователям этого софта, у которых вместо ошибки "Firebird опять не находит BLOB, с ним такое бывает" будет четкая ошибка одного из трех выше описанных видов.

почитайте что ли какое-нибудь сравнение ошибок в GCC и CLang именно в разрезе понятности "а что случилось и теперь делать-то?". Разработчики CLang, в отличие от разработчиков GCC, посчитали, что понятные сообщения об ошибках - это хорошо. Возможно, они ошибаются.


Basil A. SidorovНет желания работать с FB4 - не работай

вообще-то это МНЕ предлагали "работать с FB4", а я - отказался. Так что эта твоя филиппика - к предыдущему оратору.

Basil A. SidorovБыл эпизод, когда лично я, собственными руками, создал проблему для, примерно, 80% пользователей этой системы. И ничего, не сломался за оставшийся рабочий день...

Т.е. ты предлагаешь мне намеренно создать проблему? Или к чему это было?
Причём проблему отложенную на случайный от нас не зависящий момент, не "мой рабочий день", а - и я про это писал - "решать в моё отсутствие"/
Т.е. твой "контр-пример" - он вообще не о том.

Basil A. Sidorovне вы один попадали в "сложные жизненные ситуации".

вы мне предлагаете не случайно попасть в неё, а созщдать совбственными руками, да ещё доказать начальств, что создавтаь её нужно. Зачем настолько топорно передёргивать?

Basil A. SidorovА вот лично у меня - совершенно противоположное мнение

Поэтому я и говорю, что у разработчиков FB цель - переораклить оракл, а "беспроблемное существование программ малого и среднего размера" когда-то бывшее нишей IB и причиной его распространения их перестало занимать. Ты это сейчас просто подтвердил. Это для меня не новость.

Симонов Денис,

он может не помешать, а помочь - определить конкретный тип ситуации и через это - какие именно проблеммные места искать в приложении и и библиотеках



Dimitry Sibiryakov,

Ну т.е. Firebird - это такая СУБД для 1% самых лучших разработчиков, и за эту привилегию надо держаться, и не упрощать жизнь 99% других разработчиков, чтобы они не полезли своими грязными лапами к элитной жар-птице

вполне чёткое позиционирование, респекут и уважуха