Details

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

      Description

      A feature which is similar to the SQL 'as' can be helpful

      see the mail thread

      http://www.lucidimagination.com/search/document/63b63edc15092922/customizing_results#63b63edc15092922

      it can be implemented as a separate request param

      say

      fl.alias=from_name1:to_name1&fl.alias=from_name2:to_name2
      

        Issue Links

          Activity

          Hide
          Fergus McMenemie added a comment - - edited

          Rereading the OP's issue, I see that Nobel's solution would be fine, However a simple XSLT transform on the search output using &wt=xslt&tr=XXXX.xsl would surely be just as good and far more flexible?

          Considering this from the query side, the proposed example needs a bit clarification, .... at least for me. Is "from_name1" the name from the query and the "to_name1" the name of an underlying field in the index? If so, i would need:-

          fl.alias=title:placename&fl.alias=title:subject
          

          One of the fields that caused particular bother when searching across shards was that the unique ID field had to be common to all shards. Would this help here?

          Show
          Fergus McMenemie added a comment - - edited Rereading the OP's issue, I see that Nobel's solution would be fine, However a simple XSLT transform on the search output using &wt=xslt&tr=XXXX.xsl would surely be just as good and far more flexible? Considering this from the query side, the proposed example needs a bit clarification, .... at least for me. Is "from_name1" the name from the query and the "to_name1" the name of an underlying field in the index? If so, i would need:- fl.alias=title:placename&fl.alias=title:subject One of the fields that caused particular bother when searching across shards was that the unique ID field had to be common to all shards. Would this help here?
          Hide
          Noble Paul added a comment -

          However a simple XSLT transform on the search output using..

          The problem is that it would not help if you are using json/javabin/phps output formats and we cannot propose it as a solution

          just the opposite

          fl.alias=placename:title&fl.alias=subject:title
          

          This will have no impact on the query.(just like the fl parameter) . if just renames the fields in the result docs

          Show
          Noble Paul added a comment - However a simple XSLT transform on the search output using.. The problem is that it would not help if you are using json/javabin/phps output formats and we cannot propose it as a solution just the opposite fl.alias=placename:title&fl.alias=subject:title This will have no impact on the query.(just like the fl parameter) . if just renames the fields in the result docs
          Hide
          Thijs Vonk added a comment - - edited

          I already like this feature however, is it possible to conform to some standard?
          With SimpleFacetComponent (see http://wiki.apache.org/solr/SimpleFacetParameters#head-4ba81c89b265c3b5992e3292718a0d100f7251ef ) you can rename a facet.field with something like facet.field=

          {!ex=dt key=mylabel}

          doctype where the field will return as 'mylabel'

          could we do the same here? Something like

          fl={!key=title}placename,{!key=title}subject
          

          This way we can also keep the comma separated field list

          Show
          Thijs Vonk added a comment - - edited I already like this feature however, is it possible to conform to some standard? With SimpleFacetComponent (see http://wiki.apache.org/solr/SimpleFacetParameters#head-4ba81c89b265c3b5992e3292718a0d100f7251ef ) you can rename a facet.field with something like facet.field= {!ex=dt key=mylabel} doctype where the field will return as 'mylabel' could we do the same here? Something like fl={!key=title}placename,{!key=title}subject This way we can also keep the comma separated field list
          Hide
          Otis Gospodnetic added a comment -

          Am I the only person who finds that

          {!foo=bar}

          syntax very hard to parse and understand?

          Show
          Otis Gospodnetic added a comment - Am I the only person who finds that {!foo=bar} syntax very hard to parse and understand?
          Hide
          Fergus McMenemie added a comment -

          Yep!

          But I will tolerate it for the sake of consistency.

          Show
          Fergus McMenemie added a comment - Yep! But I will tolerate it for the sake of consistency.
          Hide
          Noble Paul added a comment -

          Am I the only person who finds that {!foo=bar} syntax very hard to parse and understand?

          Otis, you are not alone. The localparams syntax is hard to understand.It is ok for the purpose it serves . But I don't think we need that syntax for this usecase.

          Show
          Noble Paul added a comment - Am I the only person who finds that {!foo=bar} syntax very hard to parse and understand? Otis, you are not alone. The localparams syntax is hard to understand.It is ok for the purpose it serves . But I don't think we need that syntax for this usecase.
          Hide
          Hoss Man added a comment -

          FWIW: there have been numerious discussions in the past that people may want to familiarize themselves with about field aliasing use cases and how to try and approach it in a standardized way across different params...

          http://wiki.apache.org/solr/FieldAliasesAndGlobsInParams

          Show
          Hoss Man added a comment - FWIW: there have been numerious discussions in the past that people may want to familiarize themselves with about field aliasing use cases and how to try and approach it in a standardized way across different params... http://wiki.apache.org/solr/FieldAliasesAndGlobsInParams
          Hide
          Hoss Man added a comment -

          Bulk updating 240 Solr issues to set the Fix Version to "next" per the process outlined in this email...

          http://mail-archives.apache.org/mod_mbox/lucene-dev/201005.mbox/%3Calpine.DEB.1.10.1005251052040.24672@radix.cryptio.net%3E

          Selection criteria was "Unresolved" with a Fix Version of 1.5, 1.6, 3.1, or 4.0. email notifications were suppressed.

          A unique token for finding these 240 issues in the future: hossversioncleanup20100527

          Show
          Hoss Man added a comment - Bulk updating 240 Solr issues to set the Fix Version to "next" per the process outlined in this email... http://mail-archives.apache.org/mod_mbox/lucene-dev/201005.mbox/%3Calpine.DEB.1.10.1005251052040.24672@radix.cryptio.net%3E Selection criteria was "Unresolved" with a Fix Version of 1.5, 1.6, 3.1, or 4.0. email notifications were suppressed. A unique token for finding these 240 issues in the future: hossversioncleanup20100527
          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
          Hide
          Hoss Man added a comment -

          Bulk of fixVersion=3.6 -> fixVersion=4.0 for issues that have no assignee and have not been updated recently.

          email notification suppressed to prevent mass-spam
          psuedo-unique token identifying these issues: hoss20120321nofix36

          Show
          Hoss Man added a comment - Bulk of fixVersion=3.6 -> fixVersion=4.0 for issues that have no assignee and have not been updated recently. email notification suppressed to prevent mass-spam psuedo-unique token identifying these issues: hoss20120321nofix36
          Hide
          Hoss Man added a comment -

          This was implemented via the "DocTransformer" feature added to the fl param...

          http://wiki.apache.org/solr/CommonQueryParameters#Field_alias

          Show
          Hoss Man added a comment - This was implemented via the "DocTransformer" feature added to the fl param... http://wiki.apache.org/solr/CommonQueryParameters#Field_alias

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development