erratic-pattern commented on issue #40424: URL: https://github.com/apache/arrow/issues/40424#issuecomment-1986493196
I do think the concerns about "spec bloat" are valid. If there aren't enough of these sort of "opt-in" behaviors then it may not be worth complicating the handshake. Echoing what Andrew said, even though we would only return an error in the case of a client that doesn't recognize the new handle, we would still want to provide clear and unambiguous error messages about what went wrong. Currently we can get close but it's something like "No parameters provided for this prepared statement. If parameters were provided, then this FlightSQL client is possibly out of date." This is informing the user about 2 distinct possible problems instead of 1. Another problem with this is that you could still get this error message even on the *latest* version of your client, simply because your client has not been updated to support it. So "out-of-date" is not necessarily true either. What actually happened is that the client does not support a capability that the server needs. "out of date" is also a vague explanation that doesn't tell the user what went wrong. You could instead explain in more detail in the error message, but what should it say? "Your client does not support stateless prepared statements" Most users will not know what that means. Do you give a vague response or do you explain the full context of the problem? That's a lot of context to fit into a single error message in a way that's easy to understand for someone who doesn't have the related background information about the spec change. Having a concept of capabilities in the specification and documented somewhere would make it easier to explain what is happening and link to relevant information. But there are other possible solutions to this problem, for example having links to online error documentation somewhere. There is already a sort of concept of a "feature table" according to this [table](https://arrow.apache.org/docs/status.html#flight-sql) in the docs. I assume this is currently resolved via the `GetFlightDescriptor` call? Maybe versioning at the command level as an optional metadata field on the `FlightDescriptor` is an option instead? Versioning, either at the spec level or the command level, provides a straightforward error message. "Your client cannot add parameters to this prepared statement because it uses version X of this command/action/spec instead of version Y" This provides the necessary information to either research the specific root cause or come up with a solution (i.e. update your client) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
