Андрей Сидоров

Отвечу сам на свой вопрос.

Если хочется хранить массив названий в одном поле, то к "name" полю можно добавить "index_options": "docs", и количество вхождений слова перестанет влиять на релевантность.
Так же можно добавить "norms": { "enabled": false } и общая длина строки перестанет влиять на релевантность.
Но всё это костыли, которые не помогут для более сложных случаев, когда затем вам захочется сделать разные хитрые комбинации повышения/понижения релевантности для разных ситуаций.
Например, с массивом названий не выйдет сделать буст релевантности при полном совпадении одного из названий с искомой фразой.

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

Для понимания того, как считается релевантность очень помогла статья Theory Behind Relevance Scoring.

Так же для себя обнаружил, что на релевантность влияет, насколько часто встречается слово во всём индексе https://www.elastic.co/guide/en/elasticsearch/guid... И влияет оно порой очень сильно. Поэтому при реализации поиска по названиям idf фактор ранжирования стоит в обязательном порядке отключать https://stackoverflow.com/questions/33208587/elast... (работает в версии эластика начиная с 6.2)

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

upate table_name set position = position + 1 where position >= 5

При такой схеме при удалении элемента ничего с остальными элементами делать не нужно.

Решение оставлять "зазор между индексами" в 10-100-1000 и т.д., или делать индексы дробными совершенно не приемлимо. Оно не надёжно в долгосрочной перспективе.

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

У вас `authorized` это лямбда. Тоесть это функция, которая будет выполняться каждый раз, когда запрос придёт в рельсы.
А вот это `!authorized`, это отрицание от лямбды, оно всегда будет ложью. Это не отрицание результата выполнения лямбды, это отрицание для самого объекта лямбды.

2.3.1 :001 > ->() { false }
 => #<Proc:0x00000001f744e0@(irb):1 (lambda)>
2.3.1 :002 > !(->() { false })
 => false

Вам нужно сделать одно из двух
1) провести ребейз вашей ветки на ту ветку, куда делаете пул реквест
2) провести мерж в вашу ветку той ветки, куда делаете пул реквест

Первый вариант предпочтительнее второго, т.к. не создаёт лишнего мусора в коммитах.

# подключаете удалённый репозиторий к своему
git remote add baz https://github.com/baz/bar.git
git fetch baz

# переключаетесь на нужную ветку
git checkout baz/fuz
# и дальше ответвляетесь от неё
git checkout -b new_branch_name

Проходят оба expect. В feature тестах scenario является синонимом it из обычных тестов.
Если rspec выдал в логи, что тест прошёл, значит выполнилось всё, что в нём написано.
Чтобы убедиться в этом, попробуйте выполнить следующий код

scenario "root page" do
  visit root_path

  puts 'A'
  expect(page).to have_link("Login", href: login_path(locale: I18n.locale))
  puts 'B'
  expect(page).to have_link("Signup", href: signup_path(locale: I18n.locale))
  puts 'C'
end

Отличия есть. В первом случае код внутри класса будет видеть константы из модуля (и имена вложенных классов соответственно), а втором - нет.
Пример:

module A1
  TEST = 'zz'
end

module A1
  class B1
    def foo
      TEST
    end
  end
end

module A2
  TEST = 'zz'
end

class A2::B2
  def foo
    TEST
  end
end

A1::B1.new.foo #> "zz"
A2::B2.new.foo #> NameError: uninitialized constant A2::B2::TEST

let(:confirm_oauth) { double deliver_now: nil }
before do
  allow(ConfirmOauth).to receive(:email_confirmation)
    .and_return confirm_oauth
end
subject! { do_something_that_calls_mailer }

it do
  expect(ConfirmOauth).to have_received(:email_confirmation).with user
  expect(confirm_oauth).to have_received :deliver_now
end

Другой способ - это метод receive_message_chain https://relishapp.com/rspec/rspec-mocks/docs/worki... Он подойдёт, если не нужно проверять с какими параметрами были вызваны промежуточные методы.

В контроллере:
skip_before_action :verify_authenticity_token

либо фильтровать сразу в запросе

Post
  .where.not(id: @posts_hot.map(&:id))
  .where.not(id: Post.where(post_block_id: 2)) # magic number anipattern. лучше заменить на константу
  .where.not(id: Post.joins(:post_asset).where.not(post_asset: { quote: nil }))
  .order(created_at: :desc)
  .limit(15)

либо отфильтровать после запроса в коде

Post
  .includes(:post_asset)
  .where.not(id: @posts_hot.map(&:id))
  .order(created_at: :desc)
  .limit(15)
  .select { |post| post.post_block_id != 2 }
  .select { |post| post.post_asset.try :quote }