gerlowskija commented on PR #2079: URL: https://github.com/apache/solr/pull/2079#issuecomment-1814728136
> Our Admin UI handling of /select covers almost ever property so probably couldn't use the JS version. Yep definitely. The "approximation" in this PR falls pretty far short of what the Admin UI exposes. If we cared to, we could close a lot of that gap with very little effort. Most parameters would be trivial to add. But there's a few sticking points that are going to require a good bit more effort I think: in particular the arbitrary query-params that /select supports as placeholders/variables, and the JSON DSL. That's one of the reasons I didn't go beyond the absolute basics in this PR - I wanted the approximation to be driven by actual dogfood-able usage, and the Admin UI query screen felt out of reach for an initial pass. > However, for the V2 Query syntax, is that actually simpler from a API perspective since it's mostly "generate a lot of JSON and pass it to this end point"? Would that be easier to approximate? By the "V2 Query syntax" I assume you're talking about the JSON DSL? I guess it depends how we wanted to represent that in the OAS. For the approximation, we could definitely have a POST that takes an arbitrary map in the request body (without trying to dictate exactly what properties/fields are in that map). Eventually we're definitely going to want something more DSL-syntax aware...but for an approximation maybe treating the request-body syntax as a black box is a good-enough start? > Whether we can model each and every feature in the JSON DSL, such as query parsers, attributes, builders etc in a manner that lets us generate all those domain objects, which in turn converts the object graph to JSON, for each language? Yeah, it's a good question. Do we even want our OAS (and consequently, the generated clients) to understand the syntax for each and every one of our QParsers, nested facets, etc? Or maybe an "approximate" solution is the best one here in terms of usability for clients. (Even setting usability aside, you could imagine an approximate solution might be more flexible for supporting user's custom server-side plugins, etc.) -- 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: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
