I kind of like "Aggregation API" (or something similar). Facets/stats/analytics are all definitely "aggregations". As luck would have it, "aggregation" isn't yet used to mean something more specific in Solr (right?), so we wouldn't have the problem of "it used to mean X, but now it means Y". The term has the benefit of being both accurate (semantically sound) and also corresponds to how analogous functionality is named in comparable products. Regarding simply calling it *THE* Faceting API -- I'm afraid in practice that distinction would be lost on many users. Also, current "JSON Facet" supports aggregate functions etc... are these really best described as "facet functions" as opposed to "aggregations"?
>From my perspective +1 on "v2" being overloaded (or maybe "overloaded" is not quite the right word?). And even if v2/v3/etc. is used to describe the API, we still need a name to differentiate aggregation-type functionality from search functionality. In order to be able to refer to the replacement for facet/stat/analytics, we'd need to refer to, e.g.: "the Aggregations API, introduced in v3, descended from JSON facet API, and providing functionality to replace legacy facets, stats, and analytics". Part of what makes "v2" etc. awkward, for faceting in particular, is that "v1" was ... what, exactly? Legacy FacetComponent isn't really a self-contained API, it's kind of just a bunch of thematically related top-level request parameters. If someone informally asked me what "v2" meant in Solr, tbh I'd probably say ... "oh, that's if you use JSON" :-) IMO (similar to what Mikhail was saying iiuc) the key distinction between and "legacy"/"classic" FacetComponent and the JSON facet API is that the latter natively/idiomatically supports hierarchical configurations and aggregate functions. It would be great to have the admin UI guide users towards the new API. The strong point of the new API(s) is their hierarchical/nested aspect, which unfortunately calls for a more complex admin UI design -- "auto completing JSON editor" as Jan suggests, or even a nested form-based UI "client" that doesn't force people to manually fuss with JSON. On Sat, Feb 18, 2023 at 6:34 PM Jan Høydahl <jan....@cominvent.com> wrote: > > Would be cool if the admin ui query screen had a feature for showing the JSON > equivalent of current ui input fields. And of course a brand new auto > completing JSON editor for the new syntax! > > Jan Høydahl > > > 18. feb. 2023 kl. 14:11 skrev Eric Pugh <ep...@opensourceconnections.com>: > > > > Change the Admin UI to support the new syntax? So folks who are new to > > Solr learn the new way of doing things…. ?? > > > >> On Feb 17, 2023, at 3:46 PM, David Smiley <dsmi...@apache.org> wrote: > >> > >> +1 to Ishan's proposal. Make it *the* Faceting API, and rebrand the old > >> one to legacy or classic. The surface of the API might live on for > >> simple/trivial faceting; so maybe the word "classic" could be used if it > >> continues. > >> > >> ~ David Smiley > >> Apache Lucene/Solr Search Developer > >> http://www.linkedin.com/in/davidwsmiley > >> > >> > >>> On Fri, Feb 17, 2023 at 5:37 AM Ishan Chattopadhyaya < > >>> ichattopadhy...@gmail.com> wrote: > >>> > >>> I'd prefer the JSON faceting API to be called just Faceting API, and the > >>> other one as Legacy Faceting API (and deprecated). > >>> > >>> The moment we deprecate it, usecases will emerge where legacy faceting is > >>> faster or more functional, and we can work on supporting those going > >>> forward. > >>> > >>> In deprecated state, there could be warnings in the API response and/or > >>> logs indicating that this API is deprecated. > >>> > >>> On Fri, 17 Feb, 2023, 2:26 pm Alessandro Benedetti, <a.benede...@sease.io> > >>> wrote: > >>> > >>>> In general, I dislike the V2, V3, V<something> when rebranding a method > >>> or > >>>> a service as it doesn't add any semantic value to the name, on the other > >>>> hand, Json-API hints it has to do with JSON payloads. > >>>> > >>>> Given that, I am +1 in rebranding them, but I have no idea at the moment > >>>> for a better name than what it's currently in place ... > >>>> -------------------------- > >>>> *Alessandro Benedetti* > >>>> Director @ Sease Ltd. > >>>> *Apache Lucene/Solr Committer* > >>>> *Apache Solr PMC Member* > >>>> > >>>> e-mail: a.benede...@sease.io > >>>> > >>>> > >>>> *Sease* - Information Retrieval Applied > >>>> Consulting | Training | Open Source > >>>> > >>>> Website: Sease.io <http://sease.io/> > >>>> LinkedIn <https://linkedin.com/company/sease-ltd> | Twitter > >>>> <https://twitter.com/seaseltd> | Youtube > >>>> <https://www.youtube.com/channel/UCDx86ZKLYNpI3gzMercM7BQ> | Github > >>>> <https://github.com/seaseltd> > >>>> > >>>> > >>>> On Fri, 17 Feb 2023 at 04:29, David Smiley <dsmi...@apache.org> wrote: > >>>> > >>>>> V2 shouldn't be overloaded then *that* is a problem. Can we just call > >>>> the > >>>>> new JAX-RS stuff V3 and then voila, we call this V3 faceting API? > >>>>> > >>>>> ~ David Smiley > >>>>> Apache Lucene/Solr Search Developer > >>>>> http://www.linkedin.com/in/davidwsmiley > >>>>> > >>>>> > >>>>> On Thu, Feb 16, 2023 at 11:42 AM Houston Putman <hous...@apache.org> > >>>>> wrote: > >>>>> > >>>>>> Thanks for bringing this up! > >>>>>> > >>>>>> I agree the name of the API is bad. The thing is it's not only > >>>> faceting, > >>>>>> it's also stats/analytics. > >>>>>> > >>>>>> Maybe the "aggregation API"? but I'm not sure that's any better... > >>>>>> > >>>>>> I do think "v2" is an already overloaded term that comes with a lot > >>> of > >>>>>> baggage, so I would personally vote we steer in a different > >>> direction. > >>>>>> > >>>>>> - Houston > >>>>>> > >>>>>> On Thu, Feb 16, 2023 at 9:42 AM Jan Høydahl <jan....@cominvent.com> > >>>>> wrote: > >>>>>> > >>>>>>> Hi devs, > >>>>>>> > >>>>>>> Although it's been nagging me for a while, today it hit me that the > >>>>> "JSON > >>>>>>> request API" has a terrible name. > >>>>>>> > >>>>>>> I hope to start a discussion on re-branding it and somehow pitch it > >>>> as > >>>>>> the > >>>>>>> (not-so-new) "V2" search / facet API. Good timing as part of the > >>>> other > >>>>> V2 > >>>>>>> efforts. > >>>>>>> That may in turn lead to increased usage and take the role as the > >>>>>>> "standard" search API instead of the "alternative". > >>>>>>> > >>>>>>> Of course I know that what we normally mean as "V2" API is the > >>> /api/ > >>>>> URL, > >>>>>>> not the syntax of the payload, i.e. you can do both old-style and > >>>>>>> JSON-style queries on both V1 adn V2 search endpoint. So I'm not > >>>> sold > >>>>> on > >>>>>>> "V2" being the perfect name here. But from a pure branding > >>>> perspective, > >>>>>>> signaling that it is the "new" way, perhaps it can fly? > >>>>>>> > >>>>>>> See JIRA https://issues.apache.org/jira/browse/SOLR-16663 for some > >>>>>>> initial thougts. Please keep the broader discussion here, and more > >>>>>>> implementation related input in JIRA. > >>>>>>> > >>>>>>> Jan > >>>>>> > >>>>> > >>>> > >>> > > > > _______________________ > > Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | > > http://www.opensourceconnections.com > > <http://www.opensourceconnections.com/> | My Free/Busy > > <http://tinyurl.com/eric-cal> > > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed > > <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> > > This e-mail and all contents, including attachments, is considered to be > > Company Confidential unless explicitly stated otherwise, regardless of > > whether attachments are marked as such. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
