[
https://issues.apache.org/jira/browse/SOLR-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14060670#comment-14060670
]
Shalin Shekhar Mangar commented on SOLR-6020:
---------------------------------------------
Thanks Vitaliy.
In this case, a fieldName must be specified (even if empty) in the
solrconfig.xml. This isn't ideal. We should be able to completely omit the
fieldName declaration and still have it work. We should override init method in
UUIDUpdateProcessorFactory and set fieldName ourselves.
bq. Maybe make sense to throw exception if configured or uniqueKeyField is not
UUID type. Currently it's ignored.
+1, we should do that.
> 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
>
>
> 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]
