Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Firebird, InterBase Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7]      все
 Re: Корректное завершение gbak/isql при b/r  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10102
Arioch,

тебя почему-то не смущает string в Delphi. А ведь преобразование char/varchar в string несёт дополнительные накладные расходы и не малые. Не вижу никакой разницы с преобразованиями из/в bcd
7 окт 19, 13:23    [21988168]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Arioch
Member

Откуда:
Сообщений: 11041
Симонов Денис,

смущает, но в данном случае влезть влезть внутрь компилятора и переписать строки
1) невозможно
2) если бы было возможно - было бы весьма трудно

а вот в твоём-моём случае не надо "убирать" блокировки, достаточно их "недобавлять"

Возвращаясь к строкам и BCD, в одном англоязычном FAQ отвечала на вечный вопрос о сравнении двух float на равенство.
И "правильный" ответ был - заменить "if f1 = f2" на "if FloatToStr(f1) = FloatToStr(f2)"

В принципе - код рабочий. Но какой-то он неправильный.

Вот твой совет ради копирования raw bytes создать и потом уничтожить dynamic array - с ним на мой вкус ровно та же проблема. Накладные расходы на порядки больше самого действия.
7 окт 19, 13:36    [21988191]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10102
Arioch,

оно и в стрингах большое. Преобразование UTF8 <-> UTF-16 вызывает ничуть не меньше проблем и никто не жужжитю Уж извини работает с тем что есть. А от тебя лучших предложений пока не поступало. Вот только не надо про преобразование в double, оно не допустимо ибо несёт потерю точности.

Arioch
И "правильный" ответ был - заменить "if f1 = f2" на "if FloatToStr(f1) = FloatToStr(f2)"


хрень это а не ответ. Все давно знают что сравнивать числа с плавающей точность надо с допустимой погрешностью. Правильный ответ

if abc(f1-f2) <= eps


где eps допустимая погрешность. Хочешь переменную придумай, хочешь константу
7 окт 19, 13:43    [21988208]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10102
Симонов Денис,

поправочка abs, т.е. модуль
7 окт 19, 13:44    [21988210]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Arioch
Member

Откуда:
Сообщений: 11041
Симонов Денис
А от тебя лучших предложений пока не поступало


поступало

Arioch
В общем, если там и делать Delphi helper, то возвращать он должен не TBytes (неформатированный дамп который может совпасть по длине и внутреннему содержимому с TBcd, а может и не совпасть), а сразу готовый TBcd. И не по указателю "из" SQLDA, а "на" SQLDA.


но, конечно, удобнее вопринимать реальность выборочно

Симонов Денис
Arioch
Ё! ещё и указатель надо взять не НА DA, а ИЗ DA. Т.е. DA придётся руками парсить.


не надо там ничего парсить. Сразу видно не разбирался.

Arioch
Размер входного буфера никто не проверяет


Ну что ты написал - то и читаю

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


Это великолепно.
Т.е. две глобальных блокировки и две неизвестно какой сложности операции внутри pluggable heap manager - это нормально.
А одно сравнение integer с константой - это тормоза.

А давайте из Firebird'а все bugcheck'и уберём. Я-то рукожоп, что с меня взять, но вы-то не рукожопы, вы же чoткие пацаны.
Заодно и "дополнительных тормозов" меньше будет, сервер взлетит просто.

Arioch
с проверкой на dialect 0 SQLDA

этого не нужно. Старый диалект только для совместимости со старыми компонентами. Он не используется уже лет 15. Разве что в недрах старого BDE. В новом API этого понятия нет вообще.


Мы тут как бы про старый API говорим, про введение в классический API integer-128 и какую адаптацию *существующих* библиотек доступа это повлечёт.

Arioch
3. дёрганье хелпера, создающего "сырой" дамп в TBytes - ARC-структуре, т.е. запускающего две глобальные блокировки потоков процессора, как минимум две.


сразу видно что ты не пытался разобраться. Нет там никаких блокировок. Хелпер надо получить ровно один раз, а потом пользоваться им. В нём нет глобального состояния.
[/quote]

Сразу видно, что ты не знаешь, что такое TBytes, хотя и заговорил про string, казалось бы в тему заговорил, но... Я удивлён.
7 окт 19, 14:04    [21988249]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10102
Arioch
В общем, если там и делать Delphi helper, то возвращать он должен не TBytes


с чего бы "интерфейсам" C++ который совершенно не привязан к Embercadro такое возвращать. Если хочешь пиши сам, да там как раз есть возможность хелперы классам писать. Это уже хелперы в терминах Delphi

Arioch
Т.е. две глобальных блокировки и две неизвестно какой сложности операции внутри pluggable heap manager - это нормально.
А одно сравнение integer с константой - это тормоза.


да откуда ты их взял? Пальцем покажи. Там для получения хелпера нет ни одного интерфейса с подсчётом ссылок, да и не забывай про паттерн синглетон, не надо 100500 раз один и тот же хелпер получать.

кто мешает проверять допустимость длины буфера на клиенте? Кто мешает выделить сразу буфер нужной длины? Так-то я тебе и в SQLDA могу по указателю хрень воткнуть для любого типа

Arioch
Мы тут как бы про старый API говорим,


ты не о том. Я тебе говорю что даже старый API завязанный на SQLDA уже как 100 лет не использует понятие диалект SQLDA. Параметр есть, пишут туда что-то отличное от 0. Оно с 0 реально используется только в совсем древних компонентах, куда всё равно новые типы никто портировать не будет.

Arioch
Сразу видно, что ты не знаешь, что такое TBytes, хотя и заговорил про string, казалось бы в тему заговорил, но... Я удивлён.


посмотри как устроен TEncoding для перекодировки строк и причём там TBytes, тогда может поймёшь
7 окт 19, 14:21    [21988279]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10102
Arioch,

я это к тому, что ты так и сяк уже используешь TBytes для строк и не жужжишь не про его накладные расходы, ни про накладные расходы string. В последних версиях Delphi строки полученные из FB приходится перекодировать почти всегда (если только не AnsiString), ибо они в UTF-16, который никогда из FB не возвращается.
Чего тогда из-за bcd здесь бучу поднимаешь? Не нравится иди на c++, где это можно сделать более прямым способом.
7 окт 19, 15:01    [21988355]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 30600

ладно вам спорить то.
перекодировка нужна и там, и там.
ибо
1. нативные (RAW) типы отдаваемые клиентом, напрямую в Delphi не ложатся
(за редким исключением)
2. "интерфейсное АПИ" разрабатывалось тоже без оглядки на Delphi

Posted via ActualForum NNTP Server 1.5

7 окт 19, 15:08    [21988364]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10102
Мимопроходящий,

так я и пытаюсь ему это донести. Накладных расходов избежать не удастся в любом варианте. Тогда чего панику поднимать, мол ой неудобно сделали, тут блокировки... Там и без того накладных расходов вагон и маленькая тележка
7 окт 19, 15:11    [21988366]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Arioch
Member

Откуда:
Сообщений: 11041
Симонов Денис
В последних версиях Delphi строки полученные из FB приходится перекодировать почти всегда (если только не AnsiString), ибо они в UTF-16, который никогда из FB не возвращается.


ты серьёзно не понимаешь, что перекодирование потока байтов из одного формата в другой не приводит к глобальной блокировке всех потоков одного, а возможно и всех процессов (префикс LOCK в x86)?

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

> Не нравится иди на c++

А голову отрубать для удаления зуба - это принципиальная позиция Firebird Project ?

....не читатель, но писатель. Я ведь написал, как бы я это делал на Delphi.

Симонов Денис
посмотри как устроен TEncoding для перекодировки строк


Никогда не считал TEncoding образцом хорошего кода. Это просто тупой копипаст из C# не включая голову. Причём настолько не включая, что элементарно можно получить use after free и dangling pointer.
Потому что "цельнотянутое" API разрабатывалось для GC-языка.


Симонов Денис
Arioch
В общем, если там и делать Delphi helper, то возвращать он должен не TBytes


с чего бы "интерфейсам" C++ который совершенно не привязан к Embercadro такое возвращать. Если хочешь пиши сам, да там как раз есть возможность хелперы классам писать. Это уже хелперы в терминах Delphi


И снова подмена предмета спора.
Ты начал разговор про какой-то неофигенно удобный Delphi хелпер, ради которого стоит отказаться от классического API и существующих библиотек, а теперь переключился на какой-то "непривязанный к Эмбаркадеро" новый Delphi-интерфейс.

Arioch
Т.е. две глобальных блокировки и две неизвестно какой сложности операции внутри pluggable heap manager - это нормально.
А одно сравнение integer с константой - это тормоза.


да откуда ты их взял? Пальцем покажи.


показывал уже, снова показываю - TBytes

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


Я ж говорю, ты не знаешь что такое TBytes - но радостно его советуешь вместо memcpy как "правильное" решение. Ну как те ребята со сравнением float'ов.

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

А что, посоветованная тобой BcdFromBytes на сервере выполняется???
А мужики-то не знают.... (c)

Так-то я тебе и в SQLDA могу по указателю хрень воткнуть для любого типа

Можешь. Но там нет иллюзии безопасности. Там идёт работа с низкоуровневыми структурами данных.
А BcdFromBytes эту иллюзию создает. Принимая на вход ARC-завёрнутый буфер данных произвольной структуры и размера. И ожидая от кого-то создания этого буфера (с межпоточными блокировами и вызовоми заранее неизвестного heap manager) недокументированного размера и заполнения его в недокументированном формате. И потом убивания буфера (с межпоточными.....).

Фактически единственное относительно безопасное (на уровне source level compatibility с другими версиями Delphi или имитирующими Delphi сторонними языками) этой функции - только и исключительно использование в паре с BcdToBytes и никак кроме.

Arioch
Мы тут как бы про старый API говорим,


ты не о том. Я тебе говорю что даже старый API завязанный на SQLDA уже как 100 лет не использует понятие диалект SQLDA. Параметр есть, пишут туда что-то отличное от 0. Оно с 0 реально используется только в совсем древних компонентах, куда всё равно новые типы никто портировать не будет.


А должно быть, кстати, не "отличное от нуля", а +1, поскольку это версия DA, предназначенная для дальнейшего расширения, и изначально означавшее то же самое, что SQL dialect....

Пока этот диалект DA задокументирован - библиотеки должны ожидать его прихода от сервера, хотя бы в размере "проверить и выдать ошибку".

Хотя, конечно, ничего не проверять и тупо иметь шанс запороть память - лучше. Ведь "дополнительных тормозов" не будет.
7 окт 19, 15:49    [21988434]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Arioch
Member

Откуда:
Сообщений: 11041
Симонов Денис
Там и без того накладных расходов вагон и маленькая тележка


а поэтому давайте на ровном месте, без какой-либо пользы, сделаем ЕЩЁ БОЛЬШЕ накладных расходов

пц! пц! пц! (с)
7 окт 19, 15:52    [21988438]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Arioch
Member

Откуда:
Сообщений: 11041
Мимопроходящий
2. "интерфейсное АПИ" разрабатывалось тоже без оглядки на Delphi


Зато Delphi разрабатывался с оглядкой на классическое API 21986134
7 окт 19, 15:56    [21988446]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10102
Arioch,

сотый раз тебе повторяю. Все перекодировки строк в Delphi используют TBytes. Я не говорю что это хорошее решение, но оно так работает внутри. У тебя наверное из БД выбираются много полей с типами CHAR/VARCHAR. Ты не жужжишь? Ну так с какого перепугу беспокоиться об использовании его в Bcd?

Покажи нам тупым как правильно инициализировать Bcd прям из структуры INT128. Только кодом, не надо нам тут поток бреда нести.

Загляни в любой компонент доступа для современной Delphi. Глянь как получается string из CHAR/VARCHAR. Перевари, сильно не огорчайся.

У тебя все числа теперь NUMERIC(38, x) что ли стали? Чего это оверхед на каждом шагу чудится
7 окт 19, 16:21    [21988480]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 30600

07.10.2019 16:21, Симонов Денис пишет:
> У тебя все числа теперь NUMERIC(38, x) что ли стали?

ну, агрегаты таки уже да.
а это значит, что без изменений в библиотеке доступа не обойтись,
для нормальной работы с FB4.
даже не затачиваясь на новые фичи и типы.
поясню.
большинство (если не все) дельфийских библиотек
для мапирования RAW-типов в дельфийские типы,
не мудрствуя лукаво, запрашивают от сервера описание полей резалтсета
при помощи isc_dsql_describe().
в данном же случае, результат будет отличный от того,
на который библиотека "умеет" реагировать.
так что без напильника не обойтись.
в любом случае.

Posted via ActualForum NNTP Server 1.5

7 окт 19, 16:45    [21988515]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10102
Мимопроходящий,

делаешь в ON CONNECT триггере

SET INT128 BIND BIGINT


Если результат помещается в BIGINT, то можно не править ни одной строчки кода
7 окт 19, 16:57    [21988534]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 30600

07.10.2019 16:57, Симонов Денис пишет:
>
> делаешь в ON CONNECT триггере
> SET INT128 BIND BIGINT

кривые костыли.
в DB-конфиге ещё куда ни шло, но в триггере...

Posted via ActualForum NNTP Server 1.5

7 окт 19, 17:00    [21988539]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10102
Мимопроходящий,

да не важно где. Это новый вид запросов, так называемые "Управляющие запросы". Их позволили выполнять где угодно, в том числе и PSQL. Хотя согласен привязка типов там выглядит странно, ибо получается что потенциально мы можем менять привязку на лету.

Можно попросить параметр пока не поздно, ну или через dbp_
7 окт 19, 17:05    [21988543]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 30600

07.10.2019 17:05, Симонов Денис пишет:
> Можно попросить параметр пока не поздно, ну или через dbp_

если не затруднит, закинь в FD удочку.

Posted via ActualForum NNTP Server 1.5

7 окт 19, 17:11    [21988558]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10102
Мимопроходящий,

isc_dpb_int128_bind уже есть оказывается
7 окт 19, 17:22    [21988584]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 30600

07.10.2019 17:22, Симонов Денис пишет:
> isc_dpb_int128_bind уже есть оказывается

а в DB-конфиге?

Posted via ActualForum NNTP Server 1.5

7 окт 19, 17:27    [21988593]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10102
Мимопроходящий,

не уверен что он там нужен. Клиенты разные бывают, кто поддерживает нативный тип, кто-то нет.
ИХМО, сразу для всех ставить не правильно
7 окт 19, 17:33    [21988605]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 30600

07.10.2019 17:33, Симонов Денис пишет:
> не уверен что он там нужен. Клиенты разные бывают, кто поддерживает
> нативный тип, кто-то нет.
> ИХМО, сразу для всех ставить не правильно

основной опиньён совместимости:
унаследованный клиент должен работать БЕЗ переделок.

к тому же это ничуть не хужее триггера на коннект.

Posted via ActualForum NNTP Server 1.5

7 окт 19, 17:37    [21988610]     Ответить | Цитировать Сообщить модератору
 Re: Корректное завершение gbak/isql при b/r  [new]
hvlad
Member

Откуда:
Сообщений: 10645
Мимопроходящий
> У тебя все числа теперь NUMERIC(38, x) что ли стали?

ну, агрегаты таки уже да.
Не все. Тип агрегата выводится из типа его аргумента.
Например
sum(int) -> bigint
sum(bigint) -> numeric(38)

С какого перепугу 0.0 стал bigint - тут мы ещё разберёмся.
Не всё так страшно.
7 окт 19, 20:25    [21988764]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7]      все
Все форумы / Firebird, InterBase Ответить