Re: [Firebird-devel] Service errors returned by API
Alex Peshkoff via Firebird-devel wrote 01.09.2022 18:16: Suppose adding N buffers for stream data instead current one should not be too hard to do. But what about API for that, format of data sent to user, etc. - that should be well though before starting with this. I was thinking about new service query item isc_info_svc_multistream which is basically the same as isc_info_svc_to_eof but a) may produce several items in response buffer and b) the first byte of data is stream id with values 0-2 to be reserves for stdout-stderr and the rest is service-specific (may be configurable in service start parameters block like isc_spb_bkp_stream XXX). -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Service errors returned by API
On 8/25/22 21:52, Dimitry Sibiryakov wrote: Perhaps warnings should be returned both ways: the binary form in status and duplicate text in output. In this case applications will get them as usual and advanced ones may be interested in parsing status. I will look at what can be done here. Putting warnings (if any) into status vector is definitely not a problem, duplicating them into text output too, what may be not trivial is messages currently printed by burp-like services to stdX. Certainly we may require analyzing warnings from clients who want to receive verbose messages in machine-readable form. Is it what you want? Rather no. As written above - messages belong to (one of) output streams (I believe services API should be able to deliver multiple streams in parallel: messages and binary stream for backup as an example). I was thinking about it. Suppose adding N buffers for stream data instead current one should not be too hard to do. But what about API for that, format of data sent to user, etc. - that should be well though before starting with this. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Service errors returned by API
Alex Peshkoff via Firebird-devel wrote 25.08.2022 10:27: But here are some problems: - An error when querying service is treated by 99% of callers (starting with fbsvcmgr) as fatal one. Other errors will not be displayed. And it is the right way to handle them, IMHO. - What about warnings - yes, they probably may be used at the first glance. But once again big problems with old clients. What should return isc_service_query - success or failure? On failure one prints status and detachs from service, on success - ignores SV. Wasn't it always the way warnings were working: success in function result and requirement to parse vector to get them?.. Perhaps warnings should be returned both ways: the binary form in status and duplicate text in output. In this case applications will get them as usual and advanced ones may be interested in parsing status. - Verbose messages are already passed through isc_svc_query(). That's what they belongs to. Certainly we may require analyzing warnings from clients who want to receive verbose messages in machine-readable form. Is it what you want? Rather no. As written above - messages belong to (one of) output streams (I believe services API should be able to deliver multiple streams in parallel: messages and binary stream for backup as an example). -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Service errors returned by API (was: [FirebirdSQL/firebird] [FR] Database restore must make every effort on activating deferred indexes (Issue #7269))
On 8/24/22 20:59, Dimitry Sibiryakov wrote: Alexander Peshkov wrote 24.08.2022 19:06: On 8/24/22 14:31, Dimitry Sibiryakov wrote: > Without it services seem to be pretty useless. I think this to be suggested in devel and if nobody sees problems - feel free to add a ticket, I will implement it. Ok. But I don't think that a simple hack returning only thread exit code is a right way to go. If I was thinking that way that feature could be present since 2. 5 :-) Notice - in status vector it will be a notice that service thread failed with exit code NNN, original message with a reason for is unknown at the final point. It is not quite try. In the old dark days when the service thread just run an external utility and mindlessly redirect whole output to the client it was so. But nowadays the thread is doing whole work itself Just small notice - an ability to return errors in SV does not directly depend upon does service run as a process or as a thread. It's possible to pass SV cross-process but nobody cared about. With service threads pre-2.5 it was a mix - some errors were returned as SV, some - as text lines. so it can return a proper errors, warnings and verbose messages through isc_svc_query() as soon as they happen. But here are some problems: - An error when querying service is treated by 99% of callers (starting with fbsvcmgr) as fatal one. Other errors will not be displayed. - What about warnings - yes, they probably may be used at the first glance. But once again big problems with old clients. What should return isc_service_query - success or failure? On failure one prints status and detachs from service, on success - ignores SV. - Verbose messages are already passed through isc_svc_query(). Certainly we may require analyzing warnings from clients who want to receive verbose messages in machine-readable form. Is it what you want? Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Service errors returned by API (was: [FirebirdSQL/firebird] [FR] Database restore must make every effort on activating deferred indexes (Issue #7269))
Alexander Peshkov wrote 24.08.2022 19:06: On 8/24/22 14:31, Dimitry Sibiryakov wrote: > Without it services seem to be pretty useless. I think this to be suggested in devel and if nobody sees problems - feel free to add a ticket, I will implement it. Ok. But I don't think that a simple hack returning only thread exit code is a right way to go. Notice - in status vector it will be a notice that service thread failed with exit code NNN, original message with a reason for is unknown at the final point. It is not quite try. In the old dark days when the service thread just run an external utility and mindlessly redirect whole output to the client it was so. But nowadays the thread is doing whole work itself so it can return a proper errors, warnings and verbose messages through isc_svc_query() as soon as they happen. -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
