> Personally I'd love to see us stop maintaining the duplicated code of > the underlying implementations. I wouldn't mind losing the legacy > syntax as well - I'll take a clear, verbose API over a less-clear, > concise one any day. But I'm probably a minority there.
+1, agree with Jason here, fully. On Wed, Oct 27, 2021 at 8:37 PM Ishan Chattopadhyaya < [email protected]> wrote: > Should we deprecate classic faceting in 9x now? > > > It's worth investigating deprecating the stats component also. I believe > JSON facets covers that functionality as well. It will be painful for users > though to switch over unfortunately. > > +1, lets deprecate stats component too. > > > On Thu, Jan 28, 2021 at 5:22 AM Joel Bernstein <[email protected]> wrote: > >> It's worth investigating deprecating the stats component also. I believe >> JSON facets covers that functionality as well. It will be painful for users >> though to switch over unfortunately. >> >> >> Joel Bernstein >> http://joelsolr.blogspot.com/ >> >> >> On Fri, Jan 22, 2021 at 1:14 PM Jason Gerlowski <[email protected]> >> wrote: >> >>> Personally I'd love to see us stop maintaining the duplicated code of >>> the underlying implementations. I wouldn't mind losing the legacy >>> syntax as well - I'll take a clear, verbose API over a less-clear, >>> concise one any day. But I'm probably a minority there. >>> >>> Either way I agree with Michael when he said above that the first step >>> would have to be a parity investigation for features and performance. >>> >>> Best, >>> >>> Jason >>> >>> On Fri, Jan 22, 2021 at 10:05 AM Michael Gibney >>> <[email protected]> wrote: >>> > >>> > I agree it would make long-term sense to consolidate the backend >>> implementation. I think leaving the "classic" user-facing facet API (with >>> JSON Facet module as a backend) would be a good idea. Either way, I think a >>> first step would be checking for parity between existing backend >>> implementations -- possibly in terms of features [1], but certainly in >>> terms of performance for common use cases [2]. >>> > >>> > I think removal of the "classic" user-facing API would cause a lot of >>> consternation in the user community. I can even see a >>> non-backward-compatibility argument for preserving the "classic" >>> user-facing API: it's simpler for simple use cases. _If_ the ultimate goal >>> is removal of the "classic" user-facing API (not presuming that it is), >>> that approach could be facilitated in the short term by enticing users >>> towards "JSON Facet" API ... basically with a "feature freeze" on the >>> legacy implementation. No new features [3], no new optimizations [4] for >>> "classic"; concentrate such efforts on JSON Facet. This seems to already be >>> the de facto case, but it could be a more intentional decision -- e.g. in >>> [3] it's straightforward to extend the the proposed "facet cache" to the >>> "classic" impl ... but I could see an argument for intentionally not doing >>> so. >>> > >>> > Robert, I think your concerns about UninvertedField could be addressed >>> by the `uninvertible="false"` property (currently defaults to "true" for >>> backward compatibility iiuc; but could default to "false", or at least >>> provide the ability to set the default for all fields to "false" at node >>> level solr.xml? -- I know I've wished for the latter!). Also fwiw I'm not >>> aware of any JSON Facet processors that work with string values in RAM ... >>> I do think all JSON Facet processors use OrdinalMap now, where relevant. >>> > >>> > [1] https://issues.apache.org/jira/browse/SOLR-14921 >>> > [2] https://issues.apache.org/jira/browse/SOLR-14764 >>> > [3] https://issues.apache.org/jira/browse/SOLR-13807 >>> > [4] https://issues.apache.org/jira/browse/SOLR-10732 >>> > >>> > On Fri, Jan 22, 2021 at 12:46 AM Robert Muir <[email protected]> wrote: >>> >> >>> >> Do these two options conflate concerns of input format vs. actual >>> >> algorithm? That was always my disappointment. >>> >> >>> >> I feel like the java apis are off here at the lower level, and it >>> >> hurts the user. >>> >> I don't talk about the input format from the user, instead I mean the >>> >> execution of the faceting query. >>> >> >>> >> IMO: building top-level caches (e.g. uninvertedfield) or >>> >> on-the-fly-caches (e.g. fieldcache) is totally trappy already. >>> >> But with the uninvertedfield of json facets it does its own thing, >>> >> even if you went thru the trouble to enable docvalues at index time: >>> >> that's sad. >>> >> >>> >> the code by default should not give the user jvm >>> >> heap/garbage-collector hell. If you want to do that to yourself, for a >>> >> totally static index, IMO that should be opt-in. >>> >> >>> >> But for the record, it is no longer just two shitty choices like >>> >> "top-level vs per-segment". There are different field types, e.g. >>> >> numeric types where the per-segment approach works efficiently. >>> >> Then you have the strings, but there is a newish middle ground for >>> >> Strings: OrdinalMap (lucene Multi* interfaces do it) which builds >>> >> top-level integers structures to speed up string-faceting, but doesnt >>> >> need *string values* in ram. >>> >> It is just integers and mostly compresses as deltas. Adrien compresses >>> >> the shit out of it. >>> >> >>> >> So I'd hate for the user to lose the option here of using docvalues to >>> >> keep faceting out of heap memory, which should not be hassling them >>> >> already in 2021. >>> >> Maybe better to refactor the code such that all these concerns aren't >>> >> unexpectedly tied together. >>> >> >>> >> On Thu, Jan 21, 2021 at 10:08 PM David Smiley <[email protected]> >>> wrote: >>> >> > >>> >> > There's a JIRA issue about this from 5 years ago: >>> https://issues.apache.org/jira/browse/SOLR-7296 >>> >> > I don't recall seeing any resistance to the idea of having the JSON >>> Faceting module act as a back-end to the front-end (API surface) of Solr's >>> common/classic/original/whatever faceting API. I don't think that simple >>> API should go away; it's strength is simple/common cases that are >>> comparatively verbose in the JSON one. >>> >> > >>> >> > ~ David Smiley >>> >> > Apache Lucene/Solr Search Developer >>> >> > http://www.linkedin.com/in/davidwsmiley >>> >> > >>> >> > >>> >> > On Thu, Jan 21, 2021 at 9:57 PM Marcus Eagan <[email protected]> >>> wrote: >>> >> >> >>> >> >> Hi all, >>> >> >> >>> >> >> Sorry to spam the list. I am querying the list in such quick >>> succession because of a realization I came to while on Twitter. Is it time >>> to deprecate the Legacy Facet API? >>> >> >> >>> >> >> I understood in the past that they behaved slightly differently. >>> Now, I'm wondering if it makes sense to keep the legacy facets package as >>> it adds a burden of maintenance to the project. If some activists really >>> want it, I will abandon the effort. If the interest is very light, I >>> suppose they can package it up in a plugin. In fact, I would help if they >>> run into trouble and I am able to help. >>> >> >> >>> >> >> Anyway, let me know what you think. If it's a good idea, I will >>> head over to the chopping block. >>> >> >> >>> >> >> -- >>> >> >> Marcus Eagan >>> >> >> >>> >> >>> >> --------------------------------------------------------------------- >>> >> To unsubscribe, e-mail: [email protected] >>> >> For additional commands, e-mail: [email protected] >>> >> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>>
