Solr
  1. Solr
  2. SOLR-2134

Trie* fields should support sortMissingLast=true, and deprecate Sortable* Field Types

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.0-ALPHA
    • Component/s: Schema and Analysis
    • Labels:
      None

      Description

      With the changes in LUCENE-2649, the FieldCache also returns if the bit is valid or not. This is enough to support sortMissingLast=true with Trie* fields. Then we can get rid of the Sortable* fields

      1. SOLR-2134-SortMissingLast.patch
        75 kB
        Ryan McKinley
      2. SOLR-2134-SortMissingLast.patch
        75 kB
        Ryan McKinley
      3. SOLR-2134-SortMissingLast.patch
        63 kB
        Ryan McKinley
      4. SOLR-2134-SortMissingLast.patch
        48 kB
        Ryan McKinley
      5. SOLR-2134-tests.patch
        16 kB
        Erick Erickson

        Issue Links

          Activity

          Hide
          Ryan McKinley added a comment -

          This patch adds 'missingValue' to the lucene SortField and then passes that on to the FieldComparator. Setting the 'missingValue' to MIN_VALUE or MAX_VALUE lets you either sort the missing fields first or last.

          Since the majority of the work is actually in lucene, it may make more sense to have this as a LUCENE issue.

          The solr side still needs some tests, but wanted to get this out for folks to see.

          Show
          Ryan McKinley added a comment - This patch adds 'missingValue' to the lucene SortField and then passes that on to the FieldComparator. Setting the 'missingValue' to MIN_VALUE or MAX_VALUE lets you either sort the missing fields first or last. Since the majority of the work is actually in lucene, it may make more sense to have this as a LUCENE issue. The solr side still needs some tests, but wanted to get this out for folks to see.
          Hide
          Michael McCandless added a comment -

          This looks great!

          So it moves the "sort missing last" capability down into Lucene, it enables SortField & Comparators to use XXXValuesCreator, so that (I think) an app could make its own external source of values (ie not use the "uninversion" that FieldCache/ReaderCache uses).

          If you pass null for the missing value then the bits are not loaded in the FieldCache right? (And then the comparator behaves as it does today, ie treats these as 0, though probably we should advertise that the missing value behavior is undefined).

          Show
          Michael McCandless added a comment - This looks great! So it moves the "sort missing last" capability down into Lucene, it enables SortField & Comparators to use XXXValuesCreator, so that (I think) an app could make its own external source of values (ie not use the "uninversion" that FieldCache/ReaderCache uses). If you pass null for the missing value then the bits are not loaded in the FieldCache right? (And then the comparator behaves as it does today, ie treats these as 0, though probably we should advertise that the missing value behavior is undefined).
          Hide
          Ryan McKinley added a comment -

          If you pass null for the missing value then the bits are not loaded in the FieldCache right?

          Passing null as the missing value indicates that the Comparator should not even try looking for missing values. Setting the missing value will turn on the 'CACHE_BITS' option

          public SortField setMissingValue( Object v )
            {
              missingValue = v;
              if( missingValue != null ) {
                if( this.creator == null ) {
                  throw new IllegalArgumentException( "Missing value only works for sort fields with a CachedArray" );
                }
          
                // Set the flag to get bits 
                creator.setFlag( CachedArrayCreator.OPTION_CACHE_BITS );
              }
              return this;
            }
          

          But the Comparators only actually set the bit if the bits are in the field cache:

              @Override
              public void copy(int slot, int doc) {
                values[slot] = ( checkMissing && cached.valid != null && !cached.valid.get(doc) )
                  ? missingValue : cached.values[doc];
              }
          

          I will make a LUCENE jira issue for adding 'sort missing first/last' to SortField/XxxxComparator – and use this issue for the solr integration.

          Show
          Ryan McKinley added a comment - If you pass null for the missing value then the bits are not loaded in the FieldCache right? Passing null as the missing value indicates that the Comparator should not even try looking for missing values. Setting the missing value will turn on the 'CACHE_BITS' option public SortField setMissingValue( Object v ) { missingValue = v; if ( missingValue != null ) { if ( this .creator == null ) { throw new IllegalArgumentException( "Missing value only works for sort fields with a CachedArray" ); } // Set the flag to get bits creator.setFlag( CachedArrayCreator.OPTION_CACHE_BITS ); } return this ; } But the Comparators only actually set the bit if the bits are in the field cache: @Override public void copy( int slot, int doc) { values[slot] = ( checkMissing && cached.valid != null && !cached.valid.get(doc) ) ? missingValue : cached.values[doc]; } I will make a LUCENE jira issue for adding 'sort missing first/last' to SortField/XxxxComparator – and use this issue for the solr integration.
          Hide
          Ryan McKinley added a comment -

          Here is an updated patch that includes everything from LUCENE-2671

          This also introduces NumericFieldCacheSource in solr so that the ValueSources use the new EntryCreator API with flags set to generate the valid bits.

          I still need to get tests included for solr

          Show
          Ryan McKinley added a comment - Here is an updated patch that includes everything from LUCENE-2671 This also introduces NumericFieldCacheSource in solr so that the ValueSources use the new EntryCreator API with flags set to generate the valid bits. I still need to get tests included for solr
          Hide
          Ryan McKinley added a comment -

          this is the Tri* getSortField code:

          
            public SortField getSortField(SchemaField field, boolean top) {
              int flags = CachedArrayCreator.CACHE_VALUES_AND_BITS;
              Object missingValue = null;
              boolean sortMissingLast  = on( SORT_MISSING_LAST,  properties );
              boolean sortMissingFirst = on( SORT_MISSING_FIRST, properties );
              
              switch (type) {
                case INTEGER:
                  if( sortMissingLast ) {
                    missingValue = Integer.MAX_VALUE;
                  }
                  else if( sortMissingFirst ) {
                    missingValue = Integer.MIN_VALUE;
                  }
                  return new SortField( new IntValuesCreator( field.getName(), 
                      FieldCache.NUMERIC_UTILS_INT_PARSER, flags ), top).setMissingValue( missingValue );
                
                case FLOAT:
                  if( sortMissingLast ) {
                    missingValue = Float.MAX_VALUE;
                  }
                  else if( sortMissingFirst ) {
                    missingValue = Float.MIN_VALUE;
                  }
                  return new SortField( new FloatValuesCreator( field.getName(), 
                      FieldCache.NUMERIC_UTILS_FLOAT_PARSER, flags ), top).setMissingValue( missingValue );
                
                case DATE: // fallthrough
                case LONG:
                  if( sortMissingLast ) {
                    missingValue = Long.MAX_VALUE;
                  }
                  else if( sortMissingFirst ) {
                    missingValue = Long.MIN_VALUE;
                  }
                  return new SortField( new LongValuesCreator( field.getName(), 
                      FieldCache.NUMERIC_UTILS_LONG_PARSER, flags ), top).setMissingValue( missingValue );
                  
                case DOUBLE:
                  if( sortMissingLast ) {
                    missingValue = Double.MAX_VALUE;
                  }
                  else if( sortMissingFirst ) {
                    missingValue = Double.MIN_VALUE;
                  }
                  return new SortField( new DoubleValuesCreator( field.getName(), 
                      FieldCache.NUMERIC_UTILS_DOUBLE_PARSER, flags ), top).setMissingValue( missingValue );
                  
                default:
                  throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, "Unknown type for trie field: " + field.name);
              }
            }
          
          Show
          Ryan McKinley added a comment - this is the Tri* getSortField code: public SortField getSortField(SchemaField field, boolean top) { int flags = CachedArrayCreator.CACHE_VALUES_AND_BITS; Object missingValue = null ; boolean sortMissingLast = on( SORT_MISSING_LAST, properties ); boolean sortMissingFirst = on( SORT_MISSING_FIRST, properties ); switch (type) { case INTEGER: if ( sortMissingLast ) { missingValue = Integer .MAX_VALUE; } else if ( sortMissingFirst ) { missingValue = Integer .MIN_VALUE; } return new SortField( new IntValuesCreator( field.getName(), FieldCache.NUMERIC_UTILS_INT_PARSER, flags ), top).setMissingValue( missingValue ); case FLOAT: if ( sortMissingLast ) { missingValue = Float .MAX_VALUE; } else if ( sortMissingFirst ) { missingValue = Float .MIN_VALUE; } return new SortField( new FloatValuesCreator( field.getName(), FieldCache.NUMERIC_UTILS_FLOAT_PARSER, flags ), top).setMissingValue( missingValue ); case DATE: // fallthrough case LONG: if ( sortMissingLast ) { missingValue = Long .MAX_VALUE; } else if ( sortMissingFirst ) { missingValue = Long .MIN_VALUE; } return new SortField( new LongValuesCreator( field.getName(), FieldCache.NUMERIC_UTILS_LONG_PARSER, flags ), top).setMissingValue( missingValue ); case DOUBLE: if ( sortMissingLast ) { missingValue = Double .MAX_VALUE; } else if ( sortMissingFirst ) { missingValue = Double .MIN_VALUE; } return new SortField( new DoubleValuesCreator( field.getName(), FieldCache.NUMERIC_UTILS_DOUBLE_PARSER, flags ), top).setMissingValue( missingValue ); default : throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, "Unknown type for trie field: " + field.name); } }
          Hide
          Ryan McKinley added a comment -

          An updated patch with tests that almost works good.

          The tests for int and long fields work great, for float/double fields, it is not behaving as I would expect. Sort desc does not put the missing fields at the bottom.

          I follow the same pattern that works for int/long:

          
                case FLOAT:
                  if( sortMissingLast ) {
                    missingValue = top ? Float.MIN_VALUE : Float.MAX_VALUE;
                  }
                  else if( sortMissingFirst ) {
                    missingValue = top ? Float.MAX_VALUE : Float.MIN_VALUE;
                  }
                  return new SortField( new FloatValuesCreator( field.getName(), 
                      FieldCache.NUMERIC_UTILS_FLOAT_PARSER, flags ), top).setMissingValue( missingValue );
          

          Any ideas?

          Show
          Ryan McKinley added a comment - An updated patch with tests that almost works good. The tests for int and long fields work great, for float/double fields, it is not behaving as I would expect. Sort desc does not put the missing fields at the bottom. I follow the same pattern that works for int/long: case FLOAT: if ( sortMissingLast ) { missingValue = top ? Float .MIN_VALUE : Float .MAX_VALUE; } else if ( sortMissingFirst ) { missingValue = top ? Float .MAX_VALUE : Float .MIN_VALUE; } return new SortField( new FloatValuesCreator( field.getName(), FieldCache.NUMERIC_UTILS_FLOAT_PARSER, flags ), top).setMissingValue( missingValue ); Any ideas?
          Hide
          Uwe Schindler added a comment -

          For floats you may not use MIN_VALUE and MAX_VALUE (which is defined different for float/doubles), its NEGATIVE_INFINITY and POSITIVE_INFINITY. Thats all

          Show
          Uwe Schindler added a comment - For floats you may not use MIN_VALUE and MAX_VALUE (which is defined different for float/doubles), its NEGATIVE_INFINITY and POSITIVE_INFINITY. Thats all
          Hide
          Yonik Seeley added a comment -

          Heh, yeah - Double.MIN_VALUE is only the smallest positive number... definitely deceiving.

          Show
          Yonik Seeley added a comment - Heh, yeah - Double.MIN_VALUE is only the smallest positive number... definitely deceiving.
          Hide
          Ryan McKinley added a comment -

          Ahhh – well that fixes things!

          using top NEGATIVE_INFINITY / POSITIVE_INFINITY makes all the tests pass.

          If someone has some time, I think this is ready to go

          Show
          Ryan McKinley added a comment - Ahhh – well that fixes things! using top NEGATIVE_INFINITY / POSITIVE_INFINITY makes all the tests pass. If someone has some time, I think this is ready to go
          Hide
          Ryan McKinley added a comment -

          Anyone get a chance to look at this? I'd like to commit it soon.

          Show
          Ryan McKinley added a comment - Anyone get a chance to look at this? I'd like to commit it soon.
          Hide
          Uwe Schindler added a comment -

          I have not closely looked into it (because the Solr sorting stuff is out of my scope), but I have one comment about floats and doubles:
          The problem with the approach of setting infinity as replacement value is, that NaN values are still undefined and may be ordered before/after these infinity values. But I think the problem is minor.
          The same problem applies if you have infinity itsself or for long/double min/max values as field value, then the sorting is also undefined (the not set values should go after/before all real infinities).

          Show
          Uwe Schindler added a comment - I have not closely looked into it (because the Solr sorting stuff is out of my scope), but I have one comment about floats and doubles: The problem with the approach of setting infinity as replacement value is, that NaN values are still undefined and may be ordered before/after these infinity values. But I think the problem is minor. The same problem applies if you have infinity itsself or for long/double min/max values as field value, then the sorting is also undefined (the not set values should go after/before all real infinities).
          Hide
          Ryan McKinley added a comment -

          The problem with the approach of setting infinity as replacement value is, that NaN values are still undefined and may be ordered before/after these infinity values. But I think the problem is minor.
          The same problem applies if you have infinity itsself or for long/double min/max values as field value, then the sorting is also undefined (the not set values should go after/before all real infinities).

          what behavior would you expect when a values in NaN or +- infinity? It seems OK to have that be undefined (but towards the end)

          Alternativly we could do something like:

          
              @Override
              public void copy(int slot, int doc) {
                if( checkMissing ) {
                  if( cached.valid != null && cached.valid != null && !cached.valid.get(doc) ) {
                    values[slot] = missingValue;
                    return;
                  }
                  if( cached.values[doc] == Double.NaN ) {
                    cached.values[doc] = missingValue; //???  perhaps check sign and go 2+- that value?  2 because INFINITY may be +- 1
                  }
                  else if( cached.values[doc] == Double.POSITIVE_INFINITY ) {
                    cached.values[doc] = Double.POSITIVE_INFINITY - 1; //???  2 just 
                  }
                  else if( cached.values[doc] == Double.NEGATIVE_INFINITY ) {
                    cached.values[doc] = Double.NEGATIVE_INFINITY + 1; //???
                  }
                }
                values[slot] = cached.values[doc];
              }
          

          I have not checked that adding anything to infinity is different... it is CS, not the real world afterall

          Show
          Ryan McKinley added a comment - The problem with the approach of setting infinity as replacement value is, that NaN values are still undefined and may be ordered before/after these infinity values. But I think the problem is minor. The same problem applies if you have infinity itsself or for long/double min/max values as field value, then the sorting is also undefined (the not set values should go after/before all real infinities). what behavior would you expect when a values in NaN or +- infinity? It seems OK to have that be undefined (but towards the end) Alternativly we could do something like: @Override public void copy( int slot, int doc) { if ( checkMissing ) { if ( cached.valid != null && cached.valid != null && !cached.valid.get(doc) ) { values[slot] = missingValue; return ; } if ( cached.values[doc] == Double .NaN ) { cached.values[doc] = missingValue; //??? perhaps check sign and go 2+- that value? 2 because INFINITY may be +- 1 } else if ( cached.values[doc] == Double .POSITIVE_INFINITY ) { cached.values[doc] = Double .POSITIVE_INFINITY - 1; //??? 2 just } else if ( cached.values[doc] == Double .NEGATIVE_INFINITY ) { cached.values[doc] = Double .NEGATIVE_INFINITY + 1; //??? } } values[slot] = cached.values[doc]; } I have not checked that adding anything to infinity is different... it is CS, not the real world afterall
          Hide
          Uwe Schindler added a comment - - edited

          I don't expect adding/subtracting anything to infinity changes its value (at least the IEEE-754 specs say it should not change anything). I would keep this as it is, I wanted to just note, that the undefined value may collide with a real value. So if you have e.g. Integer.MAX_VALUE in the slot but your missingValue is also Integer.MAX_VALUE, then sorting at this place is strange. But this affects all data types and was like that since ever?

          The problem is NaN (as it is with function queries where the score is NaN):
          NaN order is not undefined but behaves different than you expect (it means if you ever compare NaN with anything using <, >, == it will return always false). This will mix up the sorting, so defining it as missingValue is maybe a good idea. But as said before, you cannot compare with NaN, it will always return false, so use Double.isNan(cached.values[doc])

          Show
          Uwe Schindler added a comment - - edited I don't expect adding/subtracting anything to infinity changes its value (at least the IEEE-754 specs say it should not change anything). I would keep this as it is, I wanted to just note, that the undefined value may collide with a real value. So if you have e.g. Integer.MAX_VALUE in the slot but your missingValue is also Integer.MAX_VALUE, then sorting at this place is strange. But this affects all data types and was like that since ever? The problem is NaN (as it is with function queries where the score is NaN): NaN order is not undefined but behaves different than you expect (it means if you ever compare NaN with anything using <, >, == it will return always false). This will mix up the sorting, so defining it as missingValue is maybe a good idea. But as said before, you cannot compare with NaN, it will always return false, so use Double.isNan(cached.values [doc] )
          Hide
          Uwe Schindler added a comment -

          Maybe a good idea is to use http://download.oracle.com/javase/1.5.0/docs/api/java/lang/Double.html#compare(double, double) to compare the doubles in the comparator as it has a defined order for all values including NaN!

          Show
          Uwe Schindler added a comment - Maybe a good idea is to use http://download.oracle.com/javase/1.5.0/docs/api/java/lang/Double.html#compare(double, double) to compare the doubles in the comparator as it has a defined order for all values including NaN!
          Hide
          Michael McCandless added a comment -

          Hmmm is that going to be a perf hit (Double.compare) for the common case (no NaNs)?

          Show
          Michael McCandless added a comment - Hmmm is that going to be a perf hit (Double.compare) for the common case (no NaNs)?
          Hide
          Yonik Seeley added a comment -

          Hmmm is that going to be a perf hit (Double.compare) for the common case (no NaNs)?

          Agree. We shouldn't need to suport NaNs as a fieldcache value. If we want that in the future, it can be a different comparator.

          Show
          Yonik Seeley added a comment - Hmmm is that going to be a perf hit (Double.compare) for the common case (no NaNs)? Agree. We shouldn't need to suport NaNs as a fieldcache value. If we want that in the future, it can be a different comparator.
          Hide
          Ryan McKinley added a comment -

          Is it worth the added complexity and potential performance hit to fudge the behavior for the edge case?

          As long as things don't crash with NaN, I'm not sure if worrying about NaN vs Infinity sorting is worth it.

          I don't really care though.

          as it has a defined order

          I don't see anything in the javadocs – are you just saying it is defined because it is the same as what your JVM will do? Conceptually I guess NaN is closer to zero then Infinity, but the other way round seems just as likely.

          Show
          Ryan McKinley added a comment - Is it worth the added complexity and potential performance hit to fudge the behavior for the edge case? As long as things don't crash with NaN, I'm not sure if worrying about NaN vs Infinity sorting is worth it. I don't really care though. as it has a defined order I don't see anything in the javadocs – are you just saying it is defined because it is the same as what your JVM will do? Conceptually I guess NaN is closer to zero then Infinity, but the other way round seems just as likely.
          Hide
          Uwe Schindler added a comment - - edited

          NaN is always returning false when compared to anything. Its not JVM dependent it is mathematical correct and defined in IEEE-754 standard: http://en.wikipedia.org/wiki/NaN, http://forums.sun.com/thread.jspa?threadID=5419285

          The coolest thing is how you test for NaN (from JDK source code):

          public static public boolean isNaN(double v) {
            return (v != v);
          }
          

          This really returns only true for NaN, because as I said NaN always returns inequality in any comparison. The problem with that in Lucene's/Solr's sorting is the fact that the PriorityQueue uses lessThan which would return always false, in any case, so the PriorityQueue gets mixed up. You can see that, because NaN values are mixed between the other values, dependent on the order when they were inserted.

          So to remove the method call above use:

          if (cached.values[doc] != cached.values[doc]) // test for NaN
          

          Looks pervers but is correct g

          Not related to that: One thing about your patches, some of them already committed: Can you please use the Lucene Coding Conventions (no extra space around if statements and the opening { at the end of a method declaration is in the same line). We have a Eclipse style file in wiki.

          Show
          Uwe Schindler added a comment - - edited NaN is always returning false when compared to anything. Its not JVM dependent it is mathematical correct and defined in IEEE-754 standard: http://en.wikipedia.org/wiki/NaN , http://forums.sun.com/thread.jspa?threadID=5419285 The coolest thing is how you test for NaN (from JDK source code): public static public boolean isNaN( double v) { return (v != v); } This really returns only true for NaN, because as I said NaN always returns inequality in any comparison. The problem with that in Lucene's/Solr's sorting is the fact that the PriorityQueue uses lessThan which would return always false, in any case, so the PriorityQueue gets mixed up. You can see that, because NaN values are mixed between the other values, dependent on the order when they were inserted. So to remove the method call above use: if (cached.values[doc] != cached.values[doc]) // test for NaN Looks pervers but is correct g Not related to that: One thing about your patches, some of them already committed: Can you please use the Lucene Coding Conventions (no extra space around if statements and the opening { at the end of a method declaration is in the same line). We have a Eclipse style file in wiki.
          Hide
          Ryan McKinley added a comment -

          Committed to trunk in #1002464, this should be back ported when LUCENE-2665 is ready for 3.x

          This patch does not yet deprecate the Sortable* field types.

          Show
          Ryan McKinley added a comment - Committed to trunk in #1002464, this should be back ported when LUCENE-2665 is ready for 3.x This patch does not yet deprecate the Sortable* field types.
          Hide
          Yonik Seeley added a comment -

          trunk does not pay attention to sortMissingLast/sortMissingFirst on the field, only the fieldType for trie fields. I've got a patch in progress.

          Show
          Yonik Seeley added a comment - trunk does not pay attention to sortMissingLast/sortMissingFirst on the field, only the fieldType for trie fields. I've got a patch in progress.
          Hide
          Teun Duynstee added a comment -

          If I understood the comments at the Eurocon yesterday, this issue can be resolved. Correct?

          Show
          Teun Duynstee added a comment - If I understood the comments at the Eurocon yesterday, this issue can be resolved. Correct?
          Hide
          Uwe Schindler added a comment -

          I think the backport is still missing!

          Show
          Uwe Schindler added a comment - I think the backport is still missing!
          Hide
          Erick Erickson added a comment -

          Should we at least mark this as fixed in 4.0? Perhaps open another JIRA for back-porting? Whether or not this is in trunk is confusing as it stands, I took a quick look and see the code in trunk, so.....

          I'll be happy to do that if so.

          Show
          Erick Erickson added a comment - Should we at least mark this as fixed in 4.0? Perhaps open another JIRA for back-porting? Whether or not this is in trunk is confusing as it stands, I took a quick look and see the code in trunk, so..... I'll be happy to do that if so.
          Hide
          Teun Duynstee added a comment -

          Can't you just resolve and set the Fix Version to 4.0? Or is the Fix Version field not in use in the project?

          Show
          Teun Duynstee added a comment - Can't you just resolve and set the Fix Version to 4.0? Or is the Fix Version field not in use in the project?
          Hide
          Erick Erickson added a comment -

          Of course I can, but I'm not about to until someone who really understands the status of this patch weighs in... Yonik's comment from 02-Mar makes me nervous.

          Show
          Erick Erickson added a comment - Of course I can, but I'm not about to until someone who really understands the status of this patch weighs in... Yonik's comment from 02-Mar makes me nervous.
          Hide
          Uwe Schindler added a comment -

          The whole story is more complicated:

          The sortMissingLast/First part in Lucene is different between 3.x and trunk (4.0). The implementation in trunk is not good designed and is to be replaced by the 3.x version, which needs heavy reverting

          The Lucene 3.x version supports sortmissinglast/first (since 3.4, using a new API), but this was not yet ported to Solr. We want to first fix trunk to use the better approach and will also revert the Solr implementation when we do this. After that we have a clean start and can do: LUCENE-3443

          Show
          Uwe Schindler added a comment - The whole story is more complicated: The sortMissingLast/First part in Lucene is different between 3.x and trunk (4.0). The implementation in trunk is not good designed and is to be replaced by the 3.x version, which needs heavy reverting The Lucene 3.x version supports sortmissinglast/first (since 3.4, using a new API), but this was not yet ported to Solr. We want to first fix trunk to use the better approach and will also revert the Solr implementation when we do this. After that we have a clean start and can do: LUCENE-3443
          Hide
          Yonik Seeley added a comment -

          From a Solr user standpoint it's simple though: sortMissingLast/First works fine on trunk, and is not yet implemented in 3.x (currently 3.4)

          Show
          Yonik Seeley added a comment - From a Solr user standpoint it's simple though: sortMissingLast/First works fine on trunk, and is not yet implemented in 3.x (currently 3.4)
          Hide
          Erick Erickson added a comment -

          OK, so I'll mark this as "fixed 4.0" and open up a new JIRA referring back to this and to SOLR-3433 that mentions both trunk and 3.5, right?

          Show
          Erick Erickson added a comment - OK, so I'll mark this as "fixed 4.0" and open up a new JIRA referring back to this and to SOLR-3433 that mentions both trunk and 3.5, right?
          Hide
          Erick Erickson added a comment -

          If nobody objects, I'll do what I last mentioned. Mark this as fixed in 4.0 and raise another JIRA for the cleanup in 3.x. I'd like to do this today if possible (just so I won't forget!).

          I see the comments are already taken out of the schema.xml file, so I think doing this would accurately reflect the current state of the code.

          Show
          Erick Erickson added a comment - If nobody objects, I'll do what I last mentioned. Mark this as fixed in 4.0 and raise another JIRA for the cleanup in 3.x. I'd like to do this today if possible (just so I won't forget!). I see the comments are already taken out of the schema.xml file, so I think doing this would accurately reflect the current state of the code.
          Hide
          Uwe Schindler added a comment -

          Go for it!

          Show
          Uwe Schindler added a comment - Go for it!
          Hide
          Erick Erickson added a comment -

          But NOT fixed in 3.x. See SOLR-2881

          Show
          Erick Erickson added a comment - But NOT fixed in 3.x. See SOLR-2881
          Hide
          Erick Erickson added a comment -

          Added some tests for dates.

          Show
          Erick Erickson added a comment - Added some tests for dates.

            People

            • Assignee:
              Erick Erickson
              Reporter:
              Ryan McKinley
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development