I suppose the only reservation is with respect to breaking back compatibility with existing systems that never used it, or configured it differently. However I would say that if we don't decide to make it mandatory, those are bugs.
I will say that one of the things I discovered in the opensearch world that is super annoying is a constraint on the length of an ID. It amounts to mandating opaque ID's in some cases (such as use of a URI as an ID). Let's not do that. On Fri, Jul 11, 2025 at 11:23 AM David Smiley <dsmi...@apache.org> wrote: > Places where "id" is assumed (sometimes via a constant ID): > * CloudSolrClient.directUpdate > * HashBasedRouter (base class of CompositeIdRouter (DocRouter), and it does > call super to use that) > * AtomicUpdateDocumentMerger > * SpellCheckCollator > > An aside: CommonParams should not be the dumping ground of all constants! > Most especially not something like "id" which could have semantically > different meanings. > > On Fri, Jul 11, 2025 at 11:08 AM David Smiley <dsmi...@apache.org> wrote: > > > I've seen uniqueKey customized in a SolrCloud setting recently. I > thought > > I recalled some discussion or issues/limitations with this. I've seen a > > regret of making it customizable[1], and I concur with the sentiment. > Does > > anyone recall a custom uniqueKey posing problems? My search in JIRA > didn't > > find much. > > > > [1] > > > https://issues.apache.org/jira/browse/SOLR-6822?focusedCommentId=14234868&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14234868 > > > > ~ David Smiley > > Apache Lucene/Solr Search Developer > > http://www.linkedin.com/in/davidwsmiley > > > -- http://www.needhamsoftware.com (work) https://a.co/d/b2sZLD9 (my fantasy fiction book)
