Add time parameter to SeriesHelper #306
Conversation
|
It looks like the py26 build failed due to the pandas installation failing. I can't see anything I changed that could have any effect on that. It looks like pandas 0.18.0 was released two days ago, so perhaps it contained a breaking change? EDIT: In the release notes they mention that py26 is no longer supported -- let me know if I should open a new issue or add a new commit to this MR with a pinned version for py26. |
|
will this support sending the time including microseconds? ie, with a precision option? |
This reverts commit c25ec08, which this commit is part of PR influxdata#304.
This is preferable to time.time() because _convert_timestamp() from influxdb.line_protocol will do precision handling and conversion if a datetime object is given.
1b35824 to
10828b5
Compare
|
@aviau As discussed I updated my PR. The tests all pass except for py26 but it looks like this has already been happening in the last few travis builds. Could this have something to do with pandas 0.18.0 dropping python2.6 support? Let me know what you think. |
|
@matt-snider Thank you for your patience and thank you for the PR. This project needs some love, should you have time to work on more issues, I would welcome your help! |
|
@aviau No problem - I'm glad to help! I'll hopefully have some more time in the near future to contribute a bit more 😄 |
This PR replaces #130 and takes into account the feedback from that discussion.
This will allow the time to be specified when creating a point with
SeriesHelper. This can be done regardless of whether time was declared as a field in theSeriesHelper.Metaclass.If time is not specified the implementation defaults to using
datetime.utcnow(). This occurs at point-creation, not within the call to_json_body_(). This is important because to solve #264/#259 successive points within the same series should still be retained. If the time is recorded in_json_body_(), the points end up all having approximately the same time and you end up with a race condition and inaccurate timestamps.As I've added to the docstring for
SeriesHelper, the time can be any of the time types supported by the client (see line_protocol.py#L13). A nice thing about using adatetimeobject as the default, is that this leverages the existing precision handling in_convert_timestamp().One area on which I'd like feedback, is whether it's undesirable that if 'time' is specified as a field, but not specified at point-creation, that it won't raise a
NameErroras per the usual logic for missing fields/tags in helper.py#L104.