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

solr/CHANGES.txt

@@ -889,6 +889,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 ==================
 

solr/core/src/java/org/apache/solr/schema/DateRangeField.java

@@ -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';
       }
     }

solr/core/src/java/org/apache/solr/update/processor/FieldLengthUpdateProcessorFactory.java

@@ -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.IntPointField&lt;/str&gt;
- *     &lt;str&gt;solr.TrieLongField&lt;/str&gt;
+ *     &lt;str&gt;solr.LongPointField&lt;/str&gt;
  *   &lt;/arr&gt;
  * &lt;/processor&gt;</pre>
  */

solr/core/src/java/org/apache/solr/update/processor/FieldMutatingUpdateProcessorFactory.java

@@ -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>
  * 

solr/core/src/java/org/apache/solr/update/processor/ParseDateFieldUpdateProcessorFactory.java

@@ -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 
+ * a schema field, as well as those fields that match a schema field with a date
- * type that uses class solr.TrieDateField.
+ * field type.
  * </p>
  * <p>
  * If all values are parseable as dates (or are already Date), then the field will

solr/core/src/java/org/apache/solr/update/processor/ParseDoubleFieldUpdateProcessorFactory.java

@@ -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 
+ * a schema field, as well as those fields that match a schema field with a double
- * type that uses class solr.TrieDoubleField.
+ * field type.
  * </p>
  * <p>
  * If all values are parseable as double (or are already Double), then the field

solr/core/src/java/org/apache/solr/update/processor/ParseFloatFieldUpdateProcessorFactory.java

@@ -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 
+ * a schema field, as well as those fields that match a schema field with a float
- * type that uses class solr.TrieFloatField.
+ * field type.
  * </p>
  * <p>
  * If all values are parseable as float (or are already Float), then the field

solr/core/src/java/org/apache/solr/update/processor/ParseIntFieldUpdateProcessorFactory.java

@@ -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 
+ * a schema field, as well as those fields that match a schema field with an int
- * type that uses class solr.TrieIntField.
+ * field type.
  * </p>
  * <p>
  * If all values are parseable as int (or are already Integer), then the field

solr/core/src/java/org/apache/solr/update/processor/ParseLongFieldUpdateProcessorFactory.java

@@ -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 
+ * a schema field, as well as those fields that match a schema field with a long 
- * type that uses class solr.TrieLongField.
+ * field type.
  * </p>
  * <p>
  * If all values are parseable as long (or are already Long), then the field

solr/core/src/test/org/apache/solr/BasicFunctionalityTest.java

@@ -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...

solr/core/src/test/org/apache/solr/TestDistributedMissingSort.java

@@ -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_ml = "one_i1_ml";    // int field, sortMissingLast=true, multiValued=false
-  String sint1_mf = "two_i1_mf";    // TrieIntField, sortMissingFirst=true, multiValued=false
+  String sint1_mf = "two_i1_mf";    // int field, sortMissingFirst=true, multiValued=false
-  String long1_ml = "three_l1_ml";  // TrieLongField, sortMissingLast=true, multiValued=false
+  String long1_ml = "three_l1_ml";  // long field, sortMissingLast=true, multiValued=false
-  String long1_mf = "four_l1_mf";   // TrieLongField, sortMissingFirst=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
 

solr/core/src/test/org/apache/solr/search/CursorMarkTest.java

@@ -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")) {

solr/core/src/test/org/apache/solr/search/TestSolrQueryParser.java

@@ -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);

solr/example/films/README.txt

@@ -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
     }
 }'

solr/solr-ref-guide/src/schema-api.adoc

@@ -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
 ----

solr/solr-ref-guide/src/working-with-dates.adoc

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