I _think_ uniqueKey declaration is optional. So, both id field and uniqueKey declaration could be removed. But then, something in solrconfig.xml will also need to be adjusted as other parts of Solr functionality will need to be disabled as well, that do rely on unique key semantics.
UpdateRequestProcessor is a bit harder to setup, but is probably a better fit longer term. Of course, if you are doing Search index creation from Java and you don't need cloud/advanced functionality, maybe you don't need most of Solr and using Lucene directly will fit your needs better. Regards, Alex. On Wed, 6 Oct 2021 at 11:21, Shawn Heisey <[email protected]> wrote: > > On 10/6/21 3:39 AM, KARTHIK SHIVAKUMAR wrote: > > > Why Solr is not considering this field a internal to it's objective and > > allowing to be declared... > > I do not understand what you are asking here. > > > Solr should handle this Id with out exposing , so the same is not reflected > > by users to raise this case again and again.... > > > > If an user can directly index / search with out this field (forced to add > > )... since if solr can handle this internally for each doc created/ deleted. > > Some users might be perfectly OK with Solr always handling the uniqueKey > itself. But I can guarantee you that an enormous fraction of the user > base would not want Solr to do that. > > We do provide a way for users to do what you want -- have Solr create > the ID value when one is not provided: > > https://solr.apache.org/docs/8_10_0/solr-core/org/apache/solr/update/processor/UUIDUpdateProcessorFactory.html > > If you need help incorporating that update processor into your config, > then we would need to see your solrconfig.xml as well as your schema, > and then we may need to ask you a few questions to tailor the response > for your situation. Exactly what filename will contain your schema can > vary, most often it will be "managed-schema" with no extension. If you > are running in cloud mode, then the active config and schema will be > stored in zookeeper, not on the disk. > > Thanks, > Shawn >
