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
