мышления сфинкса сферы дающей неожиданных результатов ввода диапазона

Question

Я имею активную запись сферы, что я пытаюсь дублировать в sphinx_scope:

scope :active, -> (date) { where("DATE(?) BETWEEN active_date AND hide_date-1 ", date) } # between is inclusive 

Это достаточно близко для работы правительства, если кто-то может показать мне лучше подход:

sphinx_scope(:search_active) { |today| 
    {:with => {:active_date => 100.years.ago.to_i..today.to_s.to_time.to_i, :hide_date => today.to_s.to_time.to_i..100.years.from_now.to_i} 
    } 

(да, today.to_s.to_time.to_i немного неудобно ...)

Моя проблема заключается в том, что результаты не кажутся точными. Например, запрос без рамки дает

sphinxQL> SELECT weight(),* FROM `standard_core` WHERE MATCH('1910.15') AND `sphinx_deleted` = 0 LIMIT 0, 10 OPTION field_weights=(section_number=2); 
+----------+------+----------------+--------------------+-------------+-----------+------------+------------+-----------------------+-----------------------------------------------------------------------------------+---------------------+ 
| weight() | id | sphinx_deleted | sphinx_internal_id | active_date | hide_date | created_at | updated_at | sphinx_internal_class | title_sort                  | section_number_sort | 
+----------+------+----------------+--------------------+-------------+-----------+------------+------------+-----------------------+-----------------------------------------------------------------------------------+---------------------+ 
|  8557 | 3633 |    0 |    908 | 1436936400 | 297642704 | 1451164539 | 1451164539 | Standard    | § 1910.15 Shipyard employment.             | 1910.15    | 
|  6549 | 3637 |    0 |    909 | 1436936400 | 297642704 | 1451164539 | 1451164539 | Standard    | § 1910.15(a) Adoption and extension of established safety and health...   | 1910.15(a)   | 
|  6549 | 3641 |    0 |    910 | 1436936400 | 297642704 | 1451164539 | 1451164539 | Standard    | § 1910.15(b) Definitions. For purposes of this section:       | 1910.15(b)   | 

Но с областью, наиболее значимые результаты отсутствуют:

sphinxQL> SELECT weight() as weight,* FROM `standard_core` WHERE MATCH('1910.15') AND `active_date` BETWEEN -1672108252 AND 1482127200 AND `hide_date` BETWEEN 1482127200 AND 4639325348 AND `sphinx_deleted` = 0 ORDER BY weight DESC LIMIT 0, 10 OPTION field_weights=(section_number=2); 
+--------+------+----------------+--------------------+-------------+------------+------------+------------+-----------------------+-----------------------------------------------------------------------------------+---------------------+ 
| weight | id | sphinx_deleted | sphinx_internal_id | active_date | hide_date | created_at | updated_at | sphinx_internal_class | title_sort                  | section_number_sort | 
+--------+------+----------------+--------------------+-------------+------------+------------+------------+-----------------------+-----------------------------------------------------------------------------------+---------------------+ 
| 4566 | 5469 |    0 |    1367 | 1436936400 | 1484632800 | 1451167759 | 1451167759 | Standard    | § 1910.27(d)(1)(vi) Ladder wells shall have a clear width of at least 15...  | 1910.27(d)(1)(vi) | 
| 4549 | 5413 |    0 |    1353 | 1436936400 | 1484632800 | 1451167757 | 1451167757 | Standard    | § 1910.27(c)(2) Ladders without cages or wells. A clear width of at least 15... | 1910.27(c)(2)  | 
| 4549 | 5453 |    0 |    1363 | 1436936400 | 1484632800 | 1451167758 | 1451167758 | Standard    | § 1910.27(d)(1)(ii) Cages or wells (except as provided in subparagraph (5) of... | 1910.27(d)(1)(ii) | 

Я не думаю, что это на самом деле думает сфинкс ошибка, а скорее что-то с самим сфинксом. Или, скорее, что-то я не понимаю: p

Может ли кто-нибудь пролить свет на то, что здесь происходит?

[изменить] ------------------------------------------- --------------

ОК, с помощью @DGM, я обнаружил, что значения для hide_date неверны в записи базы данных sphinx. Для идентификатора записи 3633 запись 908 базы данных mysql имеет значение даты 2115-07-15.

'2115-07-15'.to_time.to_i 
=> 4592610000 

Очевидно, что существует немного расхождения между 297642704 и 4592610000.

Так что я либо неправильно вычисляю диапазон, либо база данных sphinx заполняется ошибкой.

индексы/standard_index.rb

ThinkingSphinx::Index.define :standard, :with => :real_time do 
    # fields 
    indexes title, :sortable => true 
    indexes content 
    indexes section_number, :sortable => true 

    # attributes 
    has active_date, :type => :timestamp 
    has hide_date, :type => :timestamp 
    has created_at, :type => :timestamp 
    has updated_at, :type => :timestamp 
end 

Является ли это потерять что-то в переводе между полем даты тузда и сфинксом меткой временем?

Answer 1

Я не совсем уверен, что проблема здесь, но некоторые мысли:

Если вы храните те даты как строковые значения, то это то, что будет передано Sphinx. Настройки :type используются только для создания конфигурационного файла Sphinx, а не для перевода значений атрибутов (хотя, безусловно, есть сильный аргумент, который они должны делать и для обоих!). Конечно, это не совсем объясняет, как 2115-07-15 становится 297642704, но может быть частью того, что играет. Опять же, только если модель возвращает hide_date как строку, а не дату.

Отдельная проблема заключается в том, что Sphinx хранит временные метки как целые без знака, поэтому ничего до 1 января 1970 года следует избегать.

Не решение проблемы, но, возможно, общая проблема: я бы рекомендовал использовать целочисленные представления самих дат в Sphinx. например 2115-07-15 становится 21150715.

Так что, то вроде следующего в вашей модели:

def hide_date_to_i 
    hide_date.to_s.gsub('-', '').to_i 
end 

И тогда в определении индекса:

has hide_date_to_i, :as => :hide_date, :type => :integer 

Вам необходимо обновить сферу соответственно, а также.

Надеюсь, что это приведет к тому, что все будет работать соответствующим образом, но если нет, по крайней мере, нужно упростить отладку значений Sphinx!

Answer 2

Ваши данные hide_date кажется слишком низким по сравнению с другими временных диапазонов: 297642704