Apache
/
lucene
mirror of https://github.com/apache/lucene.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

SOLR-11324: Clean up mention of trie fields in documentation and source comments

This commit is contained in:
Steve Rowe 2017-09-05 11:14:53 -04:00
parent aff647ecfa
commit 547228df17
16 changed files with 37 additions and 35 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
solr/CHANGES.txt
View File

@ -890,6 +890,8 @@ Other Changes
* SOLR-11261, SOLR-10966: Upgrade to Hadoop 2.7.4 to fix incompatibility with Java 9.
(Uwe Schindler)
* SOLR-11324: Clean up mention of trie fields in documentation and source comments. (Steve Rowe)
================== 6.6.1 ==================
Bug Fixes

4
solr/core/src/java/org/apache/solr/schema/DateRangeField.java
View File

@ -39,7 +39,7 @@ import org.apache.solr.util.DateMathParser;
import org.locationtech.spatial4j.shape.Shape;
/**
* A field for indexed dates and date ranges. It's mostly compatible with TrieDateField. It has the potential to allow
* A field for indexed dates and date ranges. It's mostly compatible with DatePointField. It has the potential to allow
* efficient faceting, similar to facet.enum.
*
* @see NumberRangePrefixTreeStrategy
@ -75,7 +75,7 @@ public class DateRangeField extends AbstractSpatialPrefixTreeFieldType<NumberRan
if (shape instanceof UnitNRShape) {
UnitNRShape unitShape = (UnitNRShape) shape;
if (unitShape.getLevel() == tree.getMaxLevels()) {
//fully precise date. We can be fully compatible with TrieDateField (incl. 'Z')
//fully precise date. We can be fully compatible with DatePointField (incl. 'Z')
return shape.toString() + 'Z';
}
}

6
solr/core/src/java/org/apache/solr/update/processor/FieldLengthUpdateProcessorFactory.java
View File

@ -35,7 +35,7 @@ import static org.apache.solr.update.processor.FieldValueMutatingUpdateProcessor
* <p>For example, with the configuration listed below any documents
* containing String values (such as "<code>abcdef</code>" or
* "<code>xyz</code>") in a field declared in the schema using
* <code>TrieIntField</code> or <code>TrieLongField</code>
* <code>IntPointField</code> or <code>LongPointField</code>
* would have those Strings replaced with the length of those fields as an
* Integer
* (ie: <code>6</code> and <code>3</code> respectively)
@ -43,8 +43,8 @@ import static org.apache.solr.update.processor.FieldValueMutatingUpdateProcessor
* <pre class="prettyprint">
* &lt;processor class="solr.FieldLengthUpdateProcessorFactory"&gt;
* &lt;arr name="typeClass"&gt;
* &lt;str&gt;solr.TrieIntField&lt;/str&gt;
* &lt;str&gt;solr.TrieLongField&lt;/str&gt;
* &lt;str&gt;solr.IntPointField&lt;/str&gt;
* &lt;str&gt;solr.LongPointField&lt;/str&gt;
* &lt;/arr&gt;
* &lt;/processor&gt;</pre>
*/

4
solr/core/src/java/org/apache/solr/update/processor/FieldMutatingUpdateProcessorFactory.java
View File

@ -79,7 +79,7 @@ import static org.apache.solr.update.processor.FieldMutatingUpdateProcessor.SELE
* In the ExampleFieldMutatingUpdateProcessorFactory configured below,
* fields will be mutated if the name starts with "foo" <i>or</i> "bar";
* <b>unless</b> the field name contains the substring "SKIP" <i>or</i>
* the fieldType is (or subclasses) TrieDateField. Meaning a field named
* the fieldType is (or subclasses) DatePointField. Meaning a field named
* "foo_SKIP" is guaranteed not to be selected, but a field named "bar_smith"
* that uses StrField will be selected.
* </p>
@ -92,7 +92,7 @@ import static org.apache.solr.update.processor.FieldMutatingUpdateProcessor.SELE
* &lt;str name="fieldRegex"&gt;.*SKIP.*&lt;/str&gt;
* &lt;/lst&gt;
* &lt;lst name="exclude"&gt;
* &lt;str name="typeClass"&gt;solr.TrieDateField&lt;/str&gt;
* &lt;str name="typeClass"&gt;solr.DatePointField&lt;/str&gt;
* &lt;/lst&gt;
* &lt;/processor&gt;</pre>
*

4
solr/core/src/java/org/apache/solr/update/processor/ParseDateFieldUpdateProcessorFactory.java
View File

@ -47,8 +47,8 @@ import org.slf4j.LoggerFactory;
* </p>
* <p>
* The default selection behavior is to mutate both those fields that don't match
* a schema field, as well as those fields that match a schema field with a field
* type that uses class solr.TrieDateField.
* a schema field, as well as those fields that match a schema field with a date
* field type.
* </p>
* <p>
* If all values are parseable as dates (or are already Date), then the field will

4
solr/core/src/java/org/apache/solr/update/processor/ParseDoubleFieldUpdateProcessorFactory.java
View File

@ -38,8 +38,8 @@ import java.util.Locale;
* </p>
* <p>
* The default selection behavior is to mutate both those fields that don't match
* a schema field, as well as those fields that match a schema field with a field
* type that uses class solr.TrieDoubleField.
* a schema field, as well as those fields that match a schema field with a double
* field type.
* </p>
* <p>
* If all values are parseable as double (or are already Double), then the field

4
solr/core/src/java/org/apache/solr/update/processor/ParseFloatFieldUpdateProcessorFactory.java
View File

@ -38,8 +38,8 @@ import java.util.Locale;
* </p>
* <p>
* The default selection behavior is to mutate both those fields that don't match
* a schema field, as well as those fields that match a schema field with a field
* type that uses class solr.TrieFloatField.
* a schema field, as well as those fields that match a schema field with a float
* field type.
* </p>
* <p>
* If all values are parseable as float (or are already Float), then the field

4
solr/core/src/java/org/apache/solr/update/processor/ParseIntFieldUpdateProcessorFactory.java
View File

@ -35,8 +35,8 @@ import java.util.Locale;
* </p>
* <p>
* The default selection behavior is to mutate both those fields that don't match
* a schema field, as well as those fields that match a schema field with a field
* type that uses class solr.TrieIntField.
* a schema field, as well as those fields that match a schema field with an int
* field type.
* </p>
* <p>
* If all values are parseable as int (or are already Integer), then the field

4
solr/core/src/java/org/apache/solr/update/processor/ParseLongFieldUpdateProcessorFactory.java
View File

@ -35,8 +35,8 @@ import java.util.Locale;
* </p>
* <p>
* The default selection behavior is to mutate both those fields that don't match
* a schema field, as well as those fields that match a schema field with a field
* type that uses class solr.TrieLongField.
* a schema field, as well as those fields that match a schema field with a long
* field type.
* </p>
* <p>
* If all values are parseable as long (or are already Long), then the field

2
solr/core/src/test/org/apache/solr/BasicFunctionalityTest.java
View File

@ -869,7 +869,7 @@ public class BasicFunctionalityTest extends SolrTestCaseJ4 {
// testing everything from query level is hard because
// time marches on ... and there is no easy way to reach into the
// bowels of TrieDateField and muck with the definition of "now"
// bowels of DatePointField and muck with the definition of "now"
// ...
// BUT: we can test that crazy combinations of "NOW" all work correctly,
// assuming the test doesn't take too long to run...

8
solr/core/src/test/org/apache/solr/TestDistributedMissingSort.java
View File

@ -30,10 +30,10 @@ public class TestDistributedMissingSort extends BaseDistributedSearchTestCase {
schemaString = "schema-distributed-missing-sort.xml";
}
String sint1_ml = "one_i1_ml"; // TrieIntField, sortMissingLast=true, multiValued=false
String sint1_mf = "two_i1_mf"; // TrieIntField, sortMissingFirst=true, multiValued=false
String long1_ml = "three_l1_ml"; // TrieLongField, sortMissingLast=true, multiValued=false
String long1_mf = "four_l1_mf"; // TrieLongField, sortMissingFirst=true, multiValued=false
String sint1_ml = "one_i1_ml"; // int field, sortMissingLast=true, multiValued=false
String sint1_mf = "two_i1_mf"; // int field, sortMissingFirst=true, multiValued=false
String long1_ml = "three_l1_ml"; // long field, sortMissingLast=true, multiValued=false
String long1_mf = "four_l1_mf"; // long field, sortMissingFirst=true, multiValued=false
String string1_ml = "five_s1_ml"; // StringField, sortMissingLast=true, multiValued=false
String string1_mf = "six_s1_mf"; // StringField, sortMissingFirst=true, multiValued=false

10
solr/core/src/test/org/apache/solr/search/CursorMarkTest.java
View File

@ -230,15 +230,15 @@ public class CursorMarkTest extends SolrTestCaseJ4 {
random().nextBytes(randBytes);
val = new BytesRef(randBytes);
} else if (fieldName.contains("int")) {
val = random().nextInt(); // TrieIntField
val = random().nextInt();
} else if (fieldName.contains("long")) {
val = random().nextLong(); // TrieLongField
val = random().nextLong();
} else if (fieldName.contains("float")) {
val = random().nextFloat() * random().nextInt(); // TrieFloatField
val = random().nextFloat() * random().nextInt();
} else if (fieldName.contains("double")) {
val = random().nextDouble() * random().nextInt(); // TrieDoubleField
val = random().nextDouble() * random().nextInt();
} else if (fieldName.contains("date")) {
val = random().nextLong(); // TrieDateField
val = random().nextLong();
} else if (fieldName.startsWith("currency")) {
val = random().nextDouble();
} else if (fieldName.startsWith("uuid")) {

2
solr/core/src/test/org/apache/solr/search/TestSolrQueryParser.java
View File

@ -278,7 +278,7 @@ public class TestSolrQueryParser extends SolrTestCaseJ4 {
q = qParser.getQuery();
assertEquals(26, ((TermInSetQuery)q).getTermData().size());
// large numeric filter query should use TermsQuery (for trie fields)
// large numeric filter query should use TermsQuery
qParser = QParser.getParser("foo_ti:(1 2 3 4 5 6 7 8 9 10 20 19 18 17 16 15 14 13 12 11)", req);
qParser.setIsFilter(true); // this may change in the future
qParser.setParams(params);

6
solr/example/films/README.txt
View File

@ -27,7 +27,7 @@ curl http://localhost:8983/solr/films/schema -X POST -H 'Content-type:applicatio
},
"add-field" : {
"name":"initial_release_date",
"type":"tdate",
"type":"pdate",
"stored":true
}
}'
@ -83,7 +83,7 @@ FAQ:
Why override the schema of the _name_ and _initial_release_date_ fields?
Without overriding those field types, the _name_ field would have been guessed as a multi-valued string field type
and _initial_release_date_ would have been guessed as a multi-valued tdate type. It makes more sense with this
and _initial_release_date_ would have been guessed as a multi-valued pdate type. It makes more sense with this
particular data set domain to have the movie name be a single valued general full-text searchable field,
and for the release date also to be single valued.
@ -109,7 +109,7 @@ curl http://localhost:8983/solr/films/schema -X POST -H 'Content-type:applicatio
},
"add-field" : {
"name":"initial_release_date",
"type":"tdate",
"type":"pdate",
"stored":true
}
}'

4
solr/solr-ref-guide/src/schema-api.adoc
View File

@ -94,14 +94,14 @@ The `add-field` command adds a new field definition to your schema. If a field w
All of the properties available when defining a field with manual `schema.xml` edits can be passed via the API. These request attributes are described in detail in the section <<defining-fields.adoc#defining-fields,Defining Fields>>.
For example, to define a new stored field named "sell-by", of type "tdate", you would POST the following request:
For example, to define a new stored field named "sell-by", of type "pdate", you would POST the following request:
[source,bash]
----
curl -X POST -H 'Content-type:application/json' --data-binary '{
"add-field":{
"name":"sell-by",
"type":"tdate",
"type":"pdate",
"stored":true }
}' http://localhost:8983/solr/gettingstarted/schema
----

4
solr/solr-ref-guide/src/working-with-dates.adoc
View File

@ -68,7 +68,7 @@ Solr's `DateRangeField` supports the same point in time date syntax described ab
* `[2014 TO 2014-12-01]` – From the start of 2014 till the end of the first day of December.
* `[* TO 2014-12-01]` – From the earliest representable time thru till the end of the day on 2014-12-01.
Limitations: The range syntax doesn't support embedded date math. If you specify a date instance supported by TrieDateField with date math truncating it, like `NOW/DAY`, you still get the first millisecond of that day, not the entire day's range. Exclusive ranges (using `{` & `}`) work in _queries_ but not for _indexing_ ranges.
Limitations: The range syntax doesn't support embedded date math. If you specify a date instance supported by DatePointField with date math truncating it, like `NOW/DAY`, you still get the first millisecond of that day, not the entire day's range. Exclusive ranges (using `{` & `}`) work in _queries_ but not for _indexing_ ranges.
== Date Math
@ -154,7 +154,7 @@ http://localhost:8983/solr/my_collection/select?q=*:*&facet.range=my_date_field&
== More DateRangeField Details
`DateRangeField` is almost a drop-in replacement for places where `TrieDateField` is used. The only difference is that Solr's XML or SolrJ response formats will expose the stored data as a String instead of a Date. The underlying index data for this field will be a bit larger. Queries that align to units of time a second on up should be faster than TrieDateField, especially if it's in UTC. But the main point of DateRangeField as its name suggests is to allow indexing date ranges. To do that, simply supply strings in the format shown above. It also supports specifying 3 different relational predicates between the indexed data, and the query range: `Intersects` (default), `Contains`, `Within`. You can specify the predicate by querying using the `op` local-params parameter like so:
`DateRangeField` is almost a drop-in replacement for places where `DatePointField` is used. The only difference is that Solr's XML or SolrJ response formats will expose the stored data as a String instead of a Date. The underlying index data for this field will be a bit larger. Queries that align to units of time a second on up should be faster than TrieDateField, especially if it's in UTC. But the main point of DateRangeField as its name suggests is to allow indexing date ranges. To do that, simply supply strings in the format shown above. It also supports specifying 3 different relational predicates between the indexed data, and the query range: `Intersects` (default), `Contains`, `Within`. You can specify the predicate by querying using the `op` local-params parameter like so:
[source,text]
----