+1 to "Aggregation API"! On Fri, 10 Mar 2023 at 21:02, Michael Gibney <mich...@michaelgibney.net> wrote:
> 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 > >
