Re: Is it Time to Deprecate the Legacy Facets API
> 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 < ichattopadhy...@gmail.com> 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 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 >> 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 >>> 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 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*
Re: Is it Time to Deprecate the Legacy Facets API
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 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 > 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 >> 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 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 >>
Re: Is it Time to Deprecate the Legacy Facets API
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 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 > 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 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 > 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 >
Re: Is it Time to Deprecate the Legacy Facets API
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 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 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 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 wrote: >> >> >> >> Hi all, >> >> >> >> Sorry to spam the list. I am querying the list in such quick
Re: Is it Time to Deprecate the Legacy Facets API
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 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 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 > 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
Re: Is it Time to Deprecate the Legacy Facets API
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 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 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Is it Time to Deprecate the Legacy Facets API
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 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 > >
Is it Time to Deprecate the Legacy Facets API
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