Как выполнить выборочную сортировку по атрибуту на основе связанного значения элемента или другого атрибута в MarkLogic

#marklogic #marklogic-8

#marklogic #marklogic-8

Вопрос:

Требование:

  1. Решайте напрямую через Index, не хотите открывать документы (следовательно, не рассматривая выражение FLOWR).

  2. Результаты поиска возвращают список документов заказа на поставку

  3. Заказ на поставку может содержать или не содержать строку (для целей примера)

  4. В заказе на поставку могут быть тысячи позиций, каждая из которых имеет свой тип
  5. Для типа будет только 1 строка (без дубликатов в заказе на покупку)
  6. Для сортировки: На основе одного из многих типов, выбранных пользователем во время поиска (иногда стул, иногда лампа и т.д.) Порядок сортировки на основе количества только для этого конкретного типа (например: стул)

Пример документа 1:

 <purchase-order>
  <line-items>
    <line-item type="lamp"  amount="3500"></line-item>
    <line-item type="couch"  amount="50000"></line-item>
    <line-item type="chair"  amount="40000"></line-item>
  </line-items>
 <other-stuff></other-stuff>
</purchase-order>


Sample document 2:

<purchase-order>
  <line-items>
  <line-item type="couch"  amount="10000"> </line-item>
  <line-item type="chair"  amount="80000"></line-item>
 </line-items>
 <other-stuff></other-stuff>
</purchase-order>   
  

Ожидаемая последовательность результатов:

  • Запрос на сортировку документа по количеству desc для типа chair должен возвращать последовательность документов 2 и 1
  • Запрос на сортировку документа по количеству desc для типа couch должен возвращать последовательность документов 1 и 2

Комментарии:

1. Вероятно, вам потребуется создать индекс пути для каждого из типов, например line-item[@type = "couch"]/@amount , и определить для этого отдельный порядок сортировки. Используете ли вы MarkLogic REST-api?

2. @ grtjn , мы не используем MarkLogic REST-api, но вместо этого search:search api через XQUERY У нас будут тысячи (предположим, максимум 3k) типов. Потребует ли это определения индексов пути до 3 тыс. Можете ли вы также уточнить, что вы имели в виду, говоря «определить отдельный порядок сортировки»

3. @grtjn, Что способствовало бы потреблению памяти для индекса пути определенного типа (например, «couch»), любых документов с: Надеемся, что нет потребления памяти для документов, имеющих только через d ниже: a) / заказ на покупку b) / заказ на покупку / позиции c) / заказ на покупку/позиции/ line-item d) / заказ на покупку / позиции / line-item[@type of anykind] т. е. «стул», надеясь на потребление памяти только для: e) /заказа на покупку/ позиций/line-item[@type = «диван»]

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

5. Да, 3k индексов пути. Каждый из них будет включать только документы с совпадениями, поэтому никаких mem для несоответствий.