Is there a way to give a unique ID to a field?

Elastic Stack Elasticsearch
1

I'm currently working with facets and I wish my application URL to keep
information about the facets that have been selected by the user so far.

For example:

http://www.example.com/widgets/manufacturer-bang_olufse/color-blue

Each selected facet is added to the URL and a resulting search, for all
facets in the URL, is done.

But let's say the manufacturer in this example is indexed as "Bang&Olufse",
I want to to be able to find it using the friendly token saved in the URL.
If I search using my current friendly token,"bang_olufse", I won't find
anything.

I'd like a generic way to target a specific field using a unique id/token. I
don't simply want the search to be case insensitive, I'd like a way to
create a real custom friendly URL token ("bang_olufse" for example, or even
"b_o") and have a way to find the right field using it. Is there a way to do
that?

I though about generating a unique string like "__faceturl-bang_olufse" and
append it to the content of the field itself, so a following search
for "__faceturl-[FRIENDLY_URL_TOKEN]" would find it. But this is really ugly
and force me to deal with the fact that the content contains this id that I
don't want to display.

Any suggestions on how to map a friendly URL token to a specific field?
Thanks in advance!

2

I guess my question was stupid: I simply have to add a
"manufacturer_friendly" field when indexing the record, and search on this
field using the friendly tokens from the URL!

3

I'm not too sure about my "solution" after all...

If I create a field dedicated to the "friendly" value, I have to get both
this field and the field containing the original value from a facet search :
the friendly value to create the URL token and the original value to display
the facet value to the user. The problem is, by setting both of those fields
to my query's TermsFacetBuilder, the result is a mix of both fields.. I
have no way to associate the friendly value and the original value of the
same term!

The workaround I'm thinking about is the following..

  • 3 fields: "full", "friendly" and "fullAndFriendly"

  • When I index a document, I add values in these three fields:

    • Its full value in the "full" field
    • Its generated friendly value in the "friendly" field
    • And finally a concatenated value in the "fullAndFriendly" field consisting
      in : fullValue + [uniqueSeparatorString] + friendlyValue

  • When I search, I ask ES to use the "fullAndFriendly" field for the facet
    to return. I then parse the returned value to get both full values and
    friendly values for the facet's terms (yark!).

  • I can now display the facet and its terms using the full values and build
    the URLs corresponding to this facet using the friendly values.

  • When there is a friendly facet token in the URL, I use it in my search and
    tell ES to use the "friendly" field to search this value.

There must be an easiest way to do this! :slight_smile:

4

Another possible way to reduce the number of steps (by 1) is to use a
term script where the value is similar to your fullAndFriendly field.

"facets" : {
    "manufacturers" : {
        "terms" : {
            "field" : "full",
            "size" : 10,
            "script" : "term + '[uniqueSeparatorString]' + _source.friendly"
        }
    }
}

That said, I am unable to set the uniqueSeparatorString to be anything
besides a number without getting "Error: unresolvable property or
identifier ..."

It would be great to have a value_script for term facets, but I am not
sure if that makes sense.

--
Ivan

On Sun, Aug 28, 2011 at 5:12 PM, ogregras ogregras@gmail.com wrote:

I'm not too sure about my "solution" after all...

If I create a field dedicated to the "friendly" value, I have to get both
this field and the field containing the original value from a facet search :
the friendly value to create the URL token and the original value to display
the facet value to the user. The problem is, by setting both of those fields
to my query's TermsFacetBuilder, the result is a mix of both fields.. I have
no way to associate the friendly value and the original value of the same
term!
The workaround I'm thinking about is the following..

  • 3 fields: "full", "friendly" and "fullAndFriendly"
  • When I index a document, I add values in these three fields:
    • Its full value in the "full" field
    • Its generated friendly value in the "friendly" field
    • And finally a concatenated value in the "fullAndFriendly"
      field consisting in : fullValue + [uniqueSeparatorString] + friendlyValue
  • When I search, I ask ES to use the "fullAndFriendly" field for the facet
    to return. I then parse the returned value to get both full values and
    friendly values for the facet's terms (yark!).
  • I can now display the facet and its terms using the full values and build
    the URLs corresponding to this facet using the friendly values.
  • When there is a friendly facet token in the URL, I use it in my search and
    tell ES to use the "friendly" field to search this value.

There must be an easiest way to do this! :slight_smile:

5

First, thanks for the help Ivan! I was pretty sure I would have no help with
such a specific question!

I may investigate the term scripts, I wasn't aware of those!

But since adding a custom metadata to a field doesn't seem to be currently
possible, I may also stick with my workaround. It requires 3 fields, which
is not the ideal, but it works great. I just need to make sure the friendly
tokens I generate CAN'T contain one of more of the characters that are used
in the "uniqueSeparatorString". Then by spliting the fullAndFriendly field
using lastIndexOf([uniqueSeparatorString]) , I'm 100% sure the left part is
the full value and the right part is the friendly value. But it's still
ugly...

Thanks again.

6

On Mon, Aug 29, 2011 at 11:24 AM, ogregras ogregras@gmail.com wrote:

First, thanks for the help Ivan! I was pretty sure I would have no help with
such a specific question!

I don't think your question is very specific. Your use case for
facets is typical and the combination of requiring not-analyzed fields
for the facet and user-friendly description is annoying. Luckily for
many of my use cases, the facets are known in advance, so I can
provide an external mapping between facet and friendly value.

--
Ivan