GitHub user vynazevedo added a comment to the discussion: [FlightSQL] Support detached execution for long-running DDL/DML
Long-running updates can use those commands, but the `DoPut` RPC stays open until the server returns the update result. The current Flight SQL specification doesn't give these commands a detached job handle that a client can poll later. One detail in point 1: `CommandStatementUpdate` carries the SQL statement; it isn't a parameter-binding step. For prepared statements, the split between binding via `DoPut` and execution via `GetFlightInfo` belongs to `CommandPreparedStatementQuery`. `DoPut(CommandPreparedStatementUpdate)` executes the update and returns its count. See [Query Execution](https://arrow.apache.org/docs/format/FlightSql.html#query-execution). `PollFlightInfo` works with a `FlightInfo` result and its endpoints. It doesn't define a way to retrieve a `DoPutUpdateResult` after the original update RPC has ended. Also, `record_count = -1` means an unknown count, not a pending operation or a job identifier. If you control both ends, a separate submit/status API with a durable job ID could provide that lifecycle, including the final count or error. That would be an extension rather than something ordinary Flight SQL clients can use automatically. I'd make retry/idempotency and transaction lifetime explicit there: reconnecting after a timeout mustn't accidentally execute the same update twice. GitHub link: https://github.com/apache/arrow/discussions/51333#discussioncomment-18487295 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
