Блог

Пока я могу фильтровать родителей по дочерним элементам и сортировать ответ по дочернему полю, работает как шарм. Смотрите ниже.

 GET /parent_child_meta_poc/paren_doc/_search
{
  "query": {
    "has_child": {
      "inner_hits": {},
      "type": "most_read_doc",
      "query": {
        "function_score": {
          "functions": [
            {
              "field_value_factor": {
                "factor": 1,
                "field": "read_count"
              }
            }
          ]
        }
      },
      "score_mode": "avg"
    }
  }
}
  

Источник: Matts gist

Пример дочернего сопоставления:

 {
  "mappings": {
    "most_read_doc": {
      "_parent": {
        "type": "paren_doc"
      },
      "properties": {
        "parent_uri": {
          "type": "string"
        },
        "read_count": {
          "type": "long"
        }
      }
    }
  }
}
  

Однако ограничение связано с такими требованиями, как :

Дайте мне все документы, соответствующие этим критериям поиска, возвращайте только документы, у которых есть дочерние элементы «most_read_doc» и сортируйте возвращенные родительские документы по «most_read_doc.read_count»

По сути, я хотел бы:

1. запрос к родительскому документу.
2. возвращайте только родительские результаты, у которых есть дочерний элемент «most_read_doc».
3. сортируется по «most_read_doc.read_count».

Родитель / потомок, похоже, не дотянули до 1. С любым типом запроса, приводящим к «вложенному: QueryParsingException…No запрос зарегистрирован для исключения [функции]]». Официального решения Elasticsearch для этого пока нет, основываясь на моем поиске. И до сих пор пытаюсь найти рабочую работу вокруг этого…

Другие похожие:

• Поиск дочернего элемента по родительскому полю, elastic forum. 2012, не поддерживается. -Kimchy
• Сортировка на основе родительского / дочернего поля. вложенное решение. не для моих нужд, см. Ниже

Примечание: я не могу использовать вложенные документы / объединить «read_count» с родительским, поскольку у меня есть две системы, применяющие обновления к этому индексу.

1. system x вставляет родительские документы в индекс, переопределяя любой предыдущий документ с заданным идентификатором, здесь нет возможности частичного обновления.
2. система y собирает метаданные Google Analytics для большинства читаемых документов и вставляет дочерний документ с привязкой к родительскому по идентификатору. Таким образом, system x может продолжать вставлять / заменять родительский документ, не затрагивая дочерние элементы.