GitHub user xborder created a discussion: [FlightSQL] Support detached execution for long-running DDL/DML
Hi everyone, Flight SQL defines `CommandStatementUpdate` and `CommandPreparedStatementUpdate` as `DoPut` operations. The server consumes the request, executes the statement, and returns a `DoPutUpdateResult`, usually containing the affected-row count. This works for short-running statements, but I'm looking for an alternative to avoid having to keep long lived connections when running long DML/DDL operations. `PollFlightInfo` appears relevant because it supports long-running Flight operations, but Flight SQL does not define how either update command maps to `PollFlightInfo`. >From my understanding, using a similar mechanism for DDL/DML queries is not >supported by the protocol because: 1. `DoPut(CommandStatementUpdate/CommandPreparedStatementUpdate)` is what binds parameters 2. The update count comes as a result of DoPut (i.e `PutResult(DoPutUpdateResult)`) I did some research trying to understand if other platforms supported this: - StarRocks: Does not seem to show PollFlightInfo support for updates - ClickHouse: DDL/DML and prepared updates execute synchronously through DoPut - GizmoSQL: Direct and prepared updates execute in DoPut after all parameters are consumed, with no PollFlightInfo implementation - InfluxDB: InfluxDB 3 Core uses GetFlightInfo/DoGet and leaves PollFlightInfo unimplemented - Apache Doris: Doris uses GetFlightInfo with FE/BE result retrieval, but current sources leave direct updates unimplemented, prepared updates incomplete, and provide no PollFlightInfo path ------------- Is there a scenario where `CommandStatementUpdate` and `CommandPreparedStatementUpdate` can be used for long running queries that I'm missing? GitHub link: https://github.com/apache/arrow/discussions/51333 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
