SQLRU.net: Firebird, HQbird, InterBase » Асинхронность API и сообщений об ошибках

Начало » Использование СУБД » Firebird, HQbird, InterBase » Асинхронность API и сообщений об ошибках

Показать: Сегодняшние сообщения :: Голосования :: Навигатор по сообщениям
Отправить по e-mail

Асинхронность API и сообщений об ошибках [сообщение #417]

Wed, 31 August 2022 16:34

SD
Сообщений: 435
Зарегистрирован: August 2022

Senior Member

Соотвествие сообщений об ошибках[ 5 голосов ]
1.	Совершенно пофиг	1 / 20%
2.	Неприятно, но переживёт	2 / 40%
3.	Нет, это была бы катастрофа	2 / 40%

Лично ваше приложение для работы с БД как отреагирует если, например, ошибка синтаксиса в запросе вернётся не из Prepare, а из Fetch?

Известить модератора

Re: Асинхронность API и сообщений об ошибках [сообщение #418 является ответом на сообщение #417]

Wed, 31 August 2022 16:41

МП
Сообщений: 889
Зарегистрирован: August 2022
Географическое положение: бурятский тун...

Senior Member

не вижу причин для паники

Известить модератора

Re: Асинхронность API и сообщений об ошибках [сообщение #419 является ответом на сообщение #418]

Wed, 31 August 2022 17:10

sim_84
Сообщений: 350
Зарегистрирован: June 2022

Senior Member

А у меня возник вопрос, а что это даст? Prepare он ведь далеко не только проверку корректности синтаксиса делает

Известить модератора

Re: Асинхронность API и сообщений об ошибках [сообщение #420 является ответом на сообщение #419]

Thu, 01 September 2022 00:59

SD
Сообщений: 435
Зарегистрирован: August 2022

Senior Member

Нынешний протокол Firebird: отправляем op_start_transaction - ждём op_response - отправляем op_prepare - ждём op_response - отправляем op_execute - ждём op_response - отправляем op_fetch - ждём op_response.

Если сделать по примеру X-server, например, будет: отправляем op_start_transaction - отправляем op_prepare отправляем op_execute - отправляем op_fetch - ждём op_response - ждём op_response - ждём op_response - ждём op_response.

Через интернет это две большие разницы. Птицы ведь хотят летать в облаках?..

Известить модератора

Re: Асинхронность API и сообщений об ошибках [сообщение #421 является ответом на сообщение #420]

Thu, 01 September 2022 09:18

sim_84
Сообщений: 350
Зарегистрирован: June 2022

Senior Member

ну не знаю не знаю. prepare ведь ещё может делать префетч метаданных (входной и выходной форматы). Это если только всегда готовый формат сообщений подсовывать.
В общем в таком режиме если и будет работать то с ограничениями

[Обновления: Thu, 01 September 2022 09:21]

Известить модератора

Re: Асинхронность API и сообщений об ошибках [сообщение #422 является ответом на сообщение #420]

Thu, 01 September 2022 09:45

hvlad
Сообщений: 371
Зарегистрирован: August 2022

Senior Member

SD писал(а) Thu, 01 September 2022 00:59

Нынешний протокол Firebird: отправляем op_start_transaction - ждём op_response - отправляем op_prepare - ждём op_response - отправляем op_execute - ждём op_response - отправляем op_fetch - ждём op_response.

Это не совсем так

Известить модератора

Re: Асинхронность API и сообщений об ошибках [сообщение #426 является ответом на сообщение #417]

Thu, 01 September 2022 14:43

ggreggory
Сообщений: 81
Зарегистрирован: July 2022

Member

SD писал(а) Wed, 31 August 2022 16:34

Лично ваше приложение для работы с БД как отреагирует если, например, ошибка синтаксиса в запросе вернётся не из Prepare, а из Fetch?

Зачем что-то менять? Используйте длинную читающую транзакцию, чтобы не стартовать на каждом запросе. Используйте кэш препарированных запросов, чтобы сократить кол-во Prepare.

Известить модератора

Re: Асинхронность API и сообщений об ошибках [сообщение #439 является ответом на сообщение #426]

Fri, 02 September 2022 15:23

МП
Сообщений: 889
Зарегистрирован: August 2022
Географическое положение: бурятский тун...

Senior Member

ggreggory

Зачем что-то менять? Используйте длинную читающую транзакцию, чтобы не стартовать на каждом запросе. Используйте кэш препарированных запросов, чтобы сократить кол-во Prepare.

вааще не в тему.
вопрос был не об этом.

Известить модератора

Re: Асинхронность API и сообщений об ошибках [сообщение #440 является ответом на сообщение #422]

Fri, 02 September 2022 15:26

BlackEric
Сообщений: 371
Зарегистрирован: June 2022

Senior Member

hvlad писал(а) Thu, 01 September 2022 09:45

SD писал(а) Thu, 01 September 2022 00:59
Нынешний протокол Firebird: отправляем op_start_transaction - ждём op_response - отправляем op_prepare - ждём op_response - отправляем op_execute - ждём op_response - отправляем op_fetch - ждём op_response.
Это не совсем так

А как?

Известить модератора

Re: Асинхронность API и сообщений об ошибках [сообщение #442 является ответом на сообщение #440]

Fri, 02 September 2022 17:57

hvlad
Сообщений: 371
Зарегистрирован: August 2022

Senior Member

BlackEric писал(а) Fri, 02 September 2022 15:26

hvlad писал(а) Thu, 01 September 2022 09:45
SD писал(а) Thu, 01 September 2022 00:59
Нынешний протокол Firebird: отправляем op_start_transaction - ждём op_response - отправляем op_prepare - ждём op_response - отправляем op_execute - ждём op_response - отправляем op_fetch - ждём op_response.
Это не совсем так

А как?

Начиная с fb25 некоторые типы пакетов (например op_execute) не отправляются сразу на сервер.
И SD об этом прекрасно знает.

Известить модератора

Re: Асинхронность API и сообщений об ошибках [сообщение #446 является ответом на сообщение #442]

Sat, 03 September 2022 00:35

SD
Сообщений: 435
Зарегистрирован: August 2022

Senior Member

Нет, вот как раз об op_execute я этого не знаю.

Известить модератора

Предыдущая тема:	UDR engine Java
Следующая тема:	Посоветуйте/покритикуйте как реализовать.

Переход к форуму:

-=] Вернуться вверх [=-

[ Сформировать XML ] [

] [

]

Текущее время: Sun Apr 06 09:48:34 GMT+3 2025

Общее время, затраченное на создание страницы: 0.02208 секунд