Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

write Date/Calendar/Timestamp values as long milliseconds-since-epoch values #79

Conversation

mccraigmccraig
Copy link
Contributor

since ES Date fields can always be written as a long milliseconds-since-epoch value ( http://www.elasticsearch.org/guide/reference/mapping/core-types/ ), and Date/Calendar/Timestamp can all easily be converted to such a value, it makes sense to write them so

@costin
Copy link
Member

costin commented Aug 21, 2013

We could add that but considering in the rest of the cases, the String format is used, this would not be consistent.
By the way, the reason why longs are not used is because in case of automatic mapping (default), the long will cause a numeric type to be used by ES instead of a date (hence the use of date as String).

@mccraigmccraig
Copy link
Contributor Author

currently i cant sink a date to ES, 'cos it throws an exception : so, i would rather have a long auto-map than an exception, because i can at least then get reasonable behaviour with a mapping

do you have a better solution in mind ? i'm mostly unfamiliar with ES codebase, but if it's not too onerous i can do a patch ?

@costin costin closed this in 6302ddd Aug 21, 2013
@costin
Copy link
Member

costin commented Aug 21, 2013

Just pushed a fix for this. Can you try the master - if you want I can kick off a nightly build (it will be another 10-15 min).

@mccraigmccraig
Copy link
Contributor Author

np : i can try master...

@mccraigmccraig
Copy link
Contributor Author

that seems to be working just fine. awesome ! thank you

would it fail if i had specified a custom format in my mapping though ?

@costin
Copy link
Member

costin commented Aug 21, 2013

yes it would unfortunately-that's the downside of it. However in practice it is recommended to add the custom date format in addition to the default one (which is ISO 8601).

Thanks for the feedback!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants