I don't think it should. The problem here is: this user has a codec
configuration driven by the schema.
If they removed the field from their schema but kept it in their
index, then clearly they do not care how it is encoded, so I think the
default is fine?
Index: solr/core/src/java/org/apache/solr/core/SchemaCodecFactory.java
===================================================================
--- solr/core/src/java/org/apache/solr/core/SchemaCodecFactory.java
(revision 1536490)
+++ solr/core/src/java/org/apache/solr/core/SchemaCodecFactory.java
(working copy)
@@ -54,26 +54,24 @@
codec = new Lucene46Codec() {
@Override
public PostingsFormat getPostingsFormatForField(String field) {
- final SchemaField fieldOrNull =
core.getLatestSchema().getFieldOrNull(field);
- if (fieldOrNull == null) {
- throw new IllegalArgumentException("no such field " + field);
+ final SchemaField schemaField =
core.getLatestSchema().getFieldOrNull(field);
+ if (schemaField != null) {
+ String postingsFormatName =
schemaField.getType().getPostingsFormat();
+ if (postingsFormatName != null) {
+ return PostingsFormat.forName(postingsFormatName);
+ }
}
- String postingsFormatName = fieldOrNull.getType().getPostingsFormat();
- if (postingsFormatName != null) {
- return PostingsFormat.forName(postingsFormatName);
- }
return super.getPostingsFormatForField(field);
}
@Override
public DocValuesFormat getDocValuesFormatForField(String field) {
- final SchemaField fieldOrNull =
core.getLatestSchema().getFieldOrNull(field);
- if (fieldOrNull == null) {
- throw new IllegalArgumentException("no such field " + field);
+ final SchemaField schemaField =
core.getLatestSchema().getFieldOrNull(field);
+ if (schemaField != null) {
+ String docValuesFormatName =
schemaField.getType().getDocValuesFormat();
+ if (docValuesFormatName != null) {
+ return DocValuesFormat.forName(docValuesFormatName);
+ }
}
- String docValuesFormatName =
fieldOrNull.getType().getDocValuesFormat();
- if (docValuesFormatName != null) {
- return DocValuesFormat.forName(docValuesFormatName);
- }
return super.getDocValuesFormatForField(field);
}
};
Index: solr/core/src/test/org/apache/solr/core/TestCodecSupport.java
===================================================================
--- solr/core/src/test/org/apache/solr/core/TestCodecSupport.java
(revision 1536490)
+++ solr/core/src/test/org/apache/solr/core/TestCodecSupport.java
(working copy)
@@ -83,16 +83,4 @@
assertEquals("Lucene45",
format.getDocValuesFormatForField("foo_memory").getName());
assertEquals("Lucene45",
format.getDocValuesFormatForField("bar_memory").getName());
}
-
- public void testUnknownField() {
- Codec codec = h.getCore().getCodec();
- PerFieldPostingsFormat format = (PerFieldPostingsFormat)
codec.postingsFormat();
- try {
- format.getPostingsFormatForField("notexisting");
- fail("field is not existing");
- } catch (IllegalArgumentException e) {
- //
- }
-
- }
}
On Tue, Oct 29, 2013 at 9:09 PM, Erick Erickson <[email protected]> wrote:
> Over on the user's list, there's a thread titled:
> "Background merge errors with Solr 4.4.0 on Optimize call".
>
> Person claims that they removed a field (presumably
> from the schema.xml file) and after that started hitting
> background merge issues.
>
> Does this seem right? If we try to merge segments where
> the underlying schema has changed _should_ it fail or is
> this worth a JIRA?
>
> Thanks,
> Erick
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
