Отфильтруйте объект по свойству и выберите с помощью ключа в jmespath

Извините, но AFAIK это невозможно в собственном JMESPath.
Для этой цели есть специальные встроенные функции в различных инструментах, таких как to_entries в jq.
Для jmespath.py и, следовательно, для Ansible висит запрос на вытягивание для реализации манипуляций с ключами.

Обновление: я сделал исправленную версию фильтра json_query. < br> Дополнительную информацию см. в этом ответе.

С фильтром dict2items в Ansible 2.5 и новее вы можете сделать это с помощью:

- debug:
    msg: "{{ dict(my_data | dict2items | json_query('[?value.feature.enabled].[key, value]')) }}"

Результат:

"msg": {
    "a": {
        "feature": {
            "enabled": true
        }
    }
}

Краткий ответ (TL; DR)

• На самом деле, да, это возможно только с помощью собственного jmespath
• Проблема в том, что запросы к исходному набору данных будут чрезвычайно громоздкими, поскольку исходный набор данных плохо нормализован для такого типа универсального запроса jmespath.

Пример

Следующий (слишком длинный) запрос jmespath к исходным данным в OP ...

[
  {
      "item_key":           `a`
      ,"feature_enabled":   @.a.feature.enabled
      ,source_object:       @.a
  }
  ,{
      "item_key":           `b`
      ,"feature_enabled":   @.b.feature.enabled
      ,source_object:       @.b
  }
  ,{
      "item_key":           `c`
      ,"feature_enabled":   @.c.feature.enabled
      ,source_object:       @.c
  }
]|[? feature_enabled == `true`]

... дает следующий результат

[
  {
    "item_key": "a",
    "feature_enabled": true,
    "source_object": {
      "feature": {
        "enabled": true
      }
    }
  }
]

Это идентично или по существу похоже на желаемый результат, но тот факт, что нам пришлось согнуть мозг, чтобы добиться этого, предполагает, что мы пытаемся протолкнуть квадратный колышек через круглое отверстие.

Ловушки

Причина, по которой этот запрос jmespath выглядит таким длинным и громоздким, заключается в том, что сам исходный набор данных плохо нормализован для общего запроса jmespath.

Это потому, что он использует ключи объекта в качестве метода сортировки верхнего уровня, когда было бы достаточно списка с последовательным индексированием.

Всякий раз, когда у вас есть набор данных, который потенциально может содержать произвольное количество значений, почти всегда предпочтительнее использовать последовательность для сопоставления верхнего уровня вместо ключей объектов.

Если вы обнаружите, что можете что-то сделать в jmespath, но вам нужно изменить свой запрос jmespath всякий раз, когда вы добавляете еще одну «запись» в свой «набор записей произвольной (нефиксированной) длины», вы сражаетесь с Jmespath вместо того, чтобы работать с ним. .

Всякий раз, когда вы видите запрос, который кажется "невозможным выполнить" с помощью Jmespath, вы почти наверняка имеете дело со структурой данных, которая использует объекты, для которых последовательности могут быть более подходящими.

Ключи объектов обычно означают фиксированное количество свойств, с которыми jmespath может справиться без проблем.

Даже свойства объекта с произвольной глубиной вложенности вполне приемлемы, если эти свойства объекта не используются в качестве замены последовательному перечислению.

Вещи начинают становиться неудобными только тогда, когда вы обнаруживаете, что вам нужно создавать последовательности-объектов, чтобы обойти объекты-объекты ... что полностью выполнимо в jmespath, но будет болезненно.

Смотрите также

• связанное сообщение о stackoverflow