Sphinx Rahmen denken unerwartete Ergebnisse von Bereichseingang Nachgeben

Question

ich einen aktiven Datensatz Umfang haben, dass ich in einem sphinx_scope zu duplizieren bin versucht:

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

Das ist nahe genug für die Regierung arbeiten, es sei denn, jemand kann mir eine bessere zeigen könnte, Ansatz:

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} 
    } 

(ja, today.to_s.to_time.to_i ist ein wenig umständlich ...)

Mein Problem ist, dass die Ergebnisse scheinen nicht genau zu sein. Zum Beispiel ergibt die Abfrage, ohne den Umfang

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)   | 

Aber mit dem Umfang, die treffendsten Ergebnisse fehlen:

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) | 

Ich glaube nicht, das ist eigentlich ein Denken Sphinx Fehler ist, sondern eher etwas mit Sphinx selbst. Oder, eher ... etwas, das ich falsch verstehe: p

Kann jemand etwas Licht auf das werfen, was hier geschieht?

[Bearbeiten] ------------------------------------------- --------------

OK, mit @DGM habe ich festgestellt, dass die Werte für hide_date im Sphinx-Datenbankeintrag nicht korrekt sind. Für die Datensatz-ID 3633 hat der MySQL-Datenbankeintrag 908 einen Datumswert von 2115-07-15.

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

Offensichtlich gibt es ein wenig Diskrepanz zwischen 297642704 und 4592610000.

Also habe ich entweder den Bereich falsch berechnet oder die Sphinx-Datenbank wird mit einem Fehler gefüllt.

Indizes/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 

Ist das zu verlieren, etwas in der Übersetzung zwischen einem MySQL-Datumsfeld und einem Sphinx Zeitstempel?

Answer 1

Ich bin nicht ganz sicher, was das Problem hier ist, aber einige Gedanken:

Wenn Sie diejenigen sind speichern Datumsangaben als String-Werte, dann wird dies an Sphinx übergeben. Die Einstellungen :type werden nur zum Generieren der Sphinx-Konfigurationsdatei verwendet, nicht zum Übersetzen von Attributwerten (obwohl es sicherlich ein starkes Argument gibt, dass sie beides tun sollten!). Natürlich erklärt das nicht ganz, wie 2115-07-15 297642704 wird, aber könnte Teil dessen sein, was gespielt wird. Auch hier nur, wenn das Modell hide_date als Zeichenfolge und nicht als Datum zurückgibt.

Ein separates Problem ist, dass Sphinx Zeitstempel als vorzeichenlose Ganzzahlen speichert, also sollte alles vor dem 1. Januar 1970 vermieden werden.

Keine Lösung für das Problem, aber vielleicht das übergeordnete Problem: Ich würde empfehlen, Integer-Darstellungen der Daten selbst in Sphinx zu verwenden. z.B. 2115-07-15 wird 21150715.

Also, so etwas wie die folgenden in Ihrem Modell:

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

Und dann in der Indexdefinition:

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

Sie benötigen, um Ihren Umfang entsprechend auch zu aktualisieren.

Hoffentlich werden die Dinge entsprechend funktionieren, aber wenn nicht, sollten zumindest die Sphinx-Werte einfacher zu debuggen!

Answer 2

Ihre hide_date Daten scheint zu niedrig zu sein im Vergleich zu den anderen Zeitbereiche: 297642704