первая мыль была curl DELETE посылать. ....

"--host elasticsearch.software.svc.cluster.local --port 9200 delete indices --older-than 7  --prefix logstash --time-unit days --timestring '%Y.%m.%d'"

олично. спасибо

если в крон будешь ставить, то в кроне процент - спецсимвол, который нужно экранировать

https://github.com/AdhityaRamadhanus/mongoes - ваще даже скомпилить не смог :(

Там в make правила для винды. Зайди в gondex и там собери. У меня скомпилилось, но конфиг не видет ))

ну и в топку... буду долбить чтобы в https://github.com/mongodb-labs/mongo-connector поправили баг с тем  что он не работает с _id отличными от objecid :)

Ola

Больной вопрос.
Поиск по товарному каталогу. Свойства хранятся в нестед поле в виде словаря из списка свойств, {свойство, подсвойство, значение и т.п.}. Т.е. в одном элементе может быть, например "тип каблука - лодочка" и "тип застежки - без застежки".
В документе еще море описательных полей, основной запрос к ним вида cross_fileds с различными весами на поля, функциями, филтрами, не суть, кросс филдс основной корень.
Теперь

Учитывая то, что нам надо искать везде, во всех полях (поэтому кросс) - мы на запрос "без каблука" и "без застежки" получим условно одинаковый набор документов, потому, что термы будут присутствовать во всех полях.

Как поженить кросс_филдс и проксимити матчинг в рамках одного нестед поля?

Сейчас решается адовым костылем через синонимы, кастомный вайтспэйс и модификацию входных данных в отдельное поле под эту задачу (удаляем пробелы между свойствами - к ним свои синонимы)

Может можно как-то прямее? Спасибо

Если честно, из этого описания не до конца понятна ситуация (откуда взялась такая сложная схема). Если вложенный атрибут представляет собой attributes: [{type: a, value: каблук - без каблука}], то все сводится к простому поиску по attributes.value. Сейчас для меня это выглядит как "мы слили все атрибуты в единую кучу, но теперь нам нужно их разобрать обратно". Если можно, было бы хорошо описать ситуацию от и до более формально.

Насколько я понимаю, нет разницы разнесем ли мы это по отдельным полям, либо это будет куча с массивом свойств. С точки зрения движка ему важно вхождение терма в какой либо филд (кросс_филд). Т.е. он нашел "без" в одном месте и доволен, затем "каблук" нашел в другом поле - победа! Складываем скоры и ура. Но тогда ему безразлично в каком именно свойстве он найдет токен "без" - а это не то поведение, которого хотелось бы добиться.

Т.е. например ищем "туфли без каблука". Делим на токены, "туфли", "без", "каблука".

У нас есть два документа:
1.  
"что" - "туфли",
"какие" - без каблука"

2.
"что" - "туфли"
"какие" - "без застежки", "тип каблука - лодочка"

Кросс_филдс по "что" и "какие" даст результат по обоим документам

я только сейчас добрался до дома, не знаю, когда смогу ответить

а в 5.0,* elasticsearch  + curator 4.2 все поменялось ?

Я хз, еще не обновляо