Uploaded image for project: 'Solr'
  1. Solr
  2. SOLR-2423

FieldType can take Object rather then String

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: 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
        ryantxu 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
        ryantxu 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
        ryantxu 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
        ryantxu 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
        ryantxu 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
        ryantxu 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
        markrmiller@gmail.com 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
        markrmiller@gmail.com 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
        ryantxu 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
        ryantxu 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
        ryantxu Ryan McKinley added a comment -

        fixed in #1086582

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

        Bulk move 3.2 -> 3.3

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

        3.4 -> 3.5

        Show
        rcmuir Robert Muir added a comment - 3.4 -> 3.5

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development