[ 
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

# Updated javadoc to link to SchemaField
# Removed formatting changes to javadocs
# Fixed javadoc which said that uniqueKey must be UUID -- that's not true 
anymore, it can be anything which accepts a string.
# Fixed a bug in UUIDUpdateProcessor which was checking for fieldName != null 
needlessly.

I think this is ready to go.

> 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, 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]

Reply via email to