gianm commented on PR #13360: URL: https://github.com/apache/druid/pull/13360#issuecomment-1345346785
> @gianm, to fix 4, how far do we want to go? That's a good question. My goal here with is avoiding a situation where someone used to the JSON API switches to SQL, tries to use a familiar parameter, finds it isn't accepted, then eventually figures out it's just spelled differently and wonders why it was necessary to change it. (Or, worse, doesn't figure that out, and assumes the SQL function doesn't support that parameter.) I believe this risk is at its highest when dealing with parameters to SQL functions that have an "equivalent" entity in the JSON API. So, for the examples you brought up: - I don't think it's necessary to change `format` to `inputFormat` in `EXTERN`. The docs all talk about using `EXTERN` with positional arguments anyway, so it doesn't much matter. - I don't think `LOCALFILES` needs to be named `LOCAL`. In fact I prefer `LOCALFILES` for the reason you mentioned. The potential for confusion isn't as strong there: I don't think there's going to be an expectation that the JSON type codes for input formats will literally become SQL function names. Maybe someone out there would assume that, but I wouldn't. - For `httpAuthenticationPassword`, as you point out, it isn't possible to keep the existing name for equivalent functionality, due to inherent differences in SQL and JSON. (JSON is more flexible in accepting various different types for the same parameter.) So in this case I think it's fine to change it to anything that seems to make sense. My wish is mainly that we keep the naming consistent unless there is some technical reason to change it, which is the case here. > I hope users appreciate these long names... They will if they are in a position where they're using both the JSON and SQL APIs: perhaps they're migrating from one to the other, or perhaps they are in a situation where some of their jobs are run with JSON and some with SQL. They won't appreciate it if they're using the SQL API only. That is a tradeoff we have to make. A thought: is it possible for the SQL API to accept two spellings of the same parameter? (Or, to accept two parameters where it would be an error to specify both unless they matched.) In that case, we could solve for both desires by having SQL accept a short and long form. The short form would be preferred by users that exclusively use SQL; the long form would be there for people that have a foot in both SQL and JSON worlds. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
