[
https://issues.apache.org/jira/browse/SOLR-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-6020:
----------------------------------------
Attachment: SOLR-6020.patch
Here's a patch which makes it possible to specify a UUIDUpdateProcessorFactory
without specifying a field name. The uniqueKey is automatically picked up in
this case.
I had to UUIDUpdateProcessorFactory inherit from UpdateRequestProcessorFactory
directly instead of going through AbstractDefaultValueUpdateProcessorFactory
because AbstractDefaultValueUpdateProcessorFactory stipulates that the
fieldName must be specified. Any workaround would have been ugly.
> Auto-generate a unique key in schema-less mode if data does not have an "id"
> field
> ----------------------------------------------------------------------------------
>
> Key: SOLR-6020
> URL: https://issues.apache.org/jira/browse/SOLR-6020
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
> Reporter: Shalin Shekhar Mangar
> Assignee: Shalin Shekhar Mangar
> Attachments: SOLR-6020.patch, SOLR-6020.patch
>
>
> Currently it is not possible to use the schema-less example if my data does
> not have an "id" field.
> I was indexing data where the unique field name was "url" in schema-less
> mode. This requires one to first change unique key name in the schema and
> then start solr and then index docs. If one had already started solr, one'd
> first need to remove managed-schema, rename schema.xml.bak to schema.xml and
> then make the necessary changes in schema.xml. I don't think we should fail
> on such simple things.
> Here's what I propose:
> # We remove "id" and uniqueKey from the managed schema example
> # If there's a field named "id" in the document, we use that as the uniqueKey
> # Else we fallback on generating a UUID or a signature field via an update
> processor and store it as the unique key field. We can name it as "id" or
> "_id"
> # But if a uniqueKey is already present in original schema.xml then we should
> expect the incoming data to have that field and we should preserve the
> current behavior of failing loudly.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
