![]() |
Home | Libraries | People | FAQ | More |
Runs a set of pipelined requests.
template< class CompletionToken =with_diagnostics_t
<asio::deferred_t>> auto async_run_pipeline( constpipeline_request
& req, std::vector<stage_response
>& res,diagnostics
& diag, CompletionToken&& token = {});
Runs the pipeline described by req
and stores its response in res
.
After the operation completes, res
will have as many elements as stages were in req
,
even if the operation fails.
Request stages are seen by the server as a series of unrelated requests. As a consequence, all stages are always run, even if previous stages fail.
If all stages succeed, the operation completes successfully. Thus, there
is no need to check the per-stage error code in res
if this operation completed successfully.
If any stage fails with a non-fatal error (as per is_fatal_error
), the result
of the operation is the first encountered error. You can check which
stages succeeded and which ones didn't by inspecting each stage in res
.
If any stage fails with a fatal error, the result of the operation is the fatal error. Successive stages will be marked as failed with the fatal error. The server may or may not have processed such stages.
The handler signature for this operation is void(boost::mysql::error_code)
.
Intermediate completion handlers, as well as the final handler, are executed
using token
's associated
executor, or this->get_executor()
if the token doesn't have an associated executor.
If the final handler has an associated immediate executor, and the operation
completes immediately, the final handler is dispatched to it. Otherwise,
the final handler is called as if it was submitted using asio::post
, and is never be called inline
from within this function.
The request and response objects must be kept alive and should not be modified until the operation completes.