Solr
  1. Solr
  2. SOLR-2423

FieldType can take Object rather then String

    Details

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

      Description

      Currently, FieldType takes a String value and converts that to whatever it uses internally – it would be great to be able to pass an Object in directly. For embeded solr, and for UpdateRequestProcessors that wish to reuse objects in various fields, this will avoid conversion to and from string.

      This is a major API change, so it should only apply to 4.0

        Activity

        Hide
        Ryan McKinley added a comment -

        This patch changes the FieldType (and SchemaField) method signatures to use Object

        -  public Fieldable createField(SchemaField field, String externalVal, float boost) {
        +  public Fieldable createField(SchemaField field, Object value, float boost) {
        

        It also changes DocumentBuilder to use the Object directly

        Show
        Ryan McKinley added a comment - This patch changes the FieldType (and SchemaField) method signatures to use Object - public Fieldable createField(SchemaField field, String externalVal, float boost) { + public Fieldable createField(SchemaField field, Object value, float boost) { It also changes DocumentBuilder to use the Object directly
        Hide
        Ryan McKinley added a comment -

        FYI, I ran into this because I am experimenting with different ways to index spatial data and want to index the same data with multiple representations. Converting to/from string each time is silly and with this the CopyField "just works"

        Show
        Ryan McKinley added a comment - FYI, I ran into this because I am experimenting with different ways to index spatial data and want to index the same data with multiple representations. Converting to/from string each time is silly and with this the CopyField "just works"
        Hide
        Ryan McKinley added a comment -

        added to trunk in #1082638, after 3.1 is released, i will port to 3.x and then resolve the issue

        Show
        Ryan McKinley added a comment - added to trunk in #1082638, after 3.1 is released, i will port to 3.x and then resolve the issue
        Hide
        Mark Miller added a comment -

        Hey Ryan -

        It seems you took out (from DocumentBuilder):

         if (sfield != null && v instanceof Date && sfield.getType() instanceof DateField) {
           DateField df = (DateField) sfield.getType();
           val = df.toInternal((Date) v) + 'Z';
         }
        

        And I have code that fails without this...was this logic moved elsewhere?

        Show
        Mark Miller added a comment - Hey Ryan - It seems you took out (from DocumentBuilder): if (sfield != null && v instanceof Date && sfield.getType() instanceof DateField) { DateField df = (DateField) sfield.getType(); val = df.toInternal((Date) v) + 'Z'; } And I have code that fails without this...was this logic moved elsewhere?
        Hide
        Ryan McKinley added a comment -

        It is in TrieDateField

            long time = (value instanceof Date) 
              ? ((Date)value).getTime() 
              : super.parseMath(null, value.toString()).getTime();
        

        Just realized that DateField uses the default createField

        I will add a test and fix now

        Show
        Ryan McKinley added a comment - It is in TrieDateField long time = (value instanceof Date) ? ((Date)value).getTime() : super .parseMath( null , value.toString()).getTime(); Just realized that DateField uses the default createField I will add a test and fix now
        Hide
        Ryan McKinley added a comment -

        fixed in #1086582

        Show
        Ryan McKinley added a comment - fixed in #1086582
        Hide
        Robert Muir added a comment -

        Bulk move 3.2 -> 3.3

        Show
        Robert Muir added a comment - Bulk move 3.2 -> 3.3
        Hide
        Robert Muir added a comment -

        3.4 -> 3.5

        Show
        Robert Muir added a comment - 3.4 -> 3.5

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development