jprante elasticsearch jdbc rzeka zmieniająca wartość daty

Question

Próbuję indeksować rekordy mysql w elastycznym wyszukuwaniu za pomocą jprante's elasticsearch jdbc river. Właśnie zauważyłem, że wartość w polu daty zmienia się w indeksie.

Mapowanie:

content_date:{ 
    "type":"date" 
} 

content_date pola rekordu w MySQL ->2012-10-06 02:11:30

po uruchomieniu JDBC rzeka ....

content_date pole do samego rekordu w elasticsearch - >2012-10-05T20:41:30Z

Rzeka:

curl -XPUT 'localhost:9200/_riv_index/_riv_type/_meta' -d '{ 
    "type" : "jdbc", 
    "jdbc" : { 
     "driver" : "com.mysql.jdbc.Driver", 
     "url" : "jdbc:mysql://localhost:3306/db", 
     "user" : "user", 
     "password" : "password", 
     "sql" : "select * from table where id=2409", 
     "poll" : "1d", 
     "versioning" : false 
    }, 
    "index" : { 
     "index" : "myindex", 
     "type" : "mytype" 
    } 
}' 

Zmiana formatu daty jest akceptowalna, ale dlaczego zmienia się wartość daty? Rzeka dodaje różnicę czasu utc do daty rekordu mysql i zapisuje ją w elastycznym wyszukiwaniu. Jak zatrzymać tę konwersję czasu?

Answer 1

Z Elasticsearch POV, oto co powiedział docs:

typu data jest specjalnym typem, który mapuje do JSON typu string. Jest on zgodny z określonym formatem, który można wyraźnie ustawić. Wszystkie daty są UTC. Wewnętrznie, data jest odwzorowywana na typ liczby długi, z dodanym etapem parsowania od ciągu do długiego i od długiego do ciąg.

Nie jesteś pewien, że możesz to zmienić.

Answer 2

Rozwiązanie tego problemu jest użycie czasową w jdbc bloku

"timezone" : "TimeZone.getDefault()" 

Również jestem datę i czas zapisywania w oddzielnym polu w mysql DB

| date | date | YES | | NULL | | 
| time | time | YES | | NULL | | 

Elasticsearch wykorzystuje Joda TimeFormat zapisać datę. Dlatego automatycznie konwertuje moją datę do datetime.

W polu daty, ponieważ nie mam czasu, automatycznie dodaje do niego zero.

Ponieważ muszę do wyświetlania danych poprzez Kibana dlatego muszę to split..I przekształcone format daty i czasu jako varchar (20) W celu obejścia tego problemu (zły pomysł, wiem) i jego pracy w porządku teraz ..