Skip to content

feature/add_influx_timestamp#24

Open
jbavari wants to merge 3 commits into
lexmag:masterfrom
jbavari:master
Open

feature/add_influx_timestamp#24
jbavari wants to merge 3 commits into
lexmag:masterfrom
jbavari:master

Conversation

@jbavari

@jbavari jbavari commented Jan 25, 2018

Copy link
Copy Markdown

@lexmag - first of all, thanks for this awesome library!

This PR addresses an issue posted here: #6. I saw the issue was tagged as 'help wanted', so here's your help!

@ebostijancic did all the hard work, I just deviated from his work a bit to specify the timestamp passed in as milliseconds and then converted to nanoseconds. He gets all the credit!

InfluxDB offers the ability to place items in the past with timestamps as per the line protocol reference.

Thanks in advance!

Comment thread lib/fluxter/packet.ex
fields = encode_fields(fields)
[header, encode_key(name), tags, ?\s, fields]

case is_nil(unix_timestamp_ms) do

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not use if?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if is a macro that just compiles down to a case statement, just went with the case instead.

@lexmag lexmag Feb 6, 2018

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if would be more expressive in this case.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jbavari then why not use if if this will be the same after compilation? If you would use Credo it would warn you that this is bad practice.

Comment thread lib/fluxter.ex
end

def write(measurement, tags, fields) when is_list(fields) do
def write(measurement, tags, fields, timestamp_milli_secs) when is_list(fields) do

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would be a braking change. Why not add default value for timestamp_milli_secs?

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hauleth is right—we need to have a default value, otherwise all existing code will be broken.

@lexmag lexmag left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @jbavari and @ebostijancic.
It is definitely the great first step towards adding timestamp support.
Millisecond precision choice seems arbitrary, though for some systems nanosecond precision is vital.
I think we should go with the way similar to DateTime.from_unix/2 for example, that is having integer value and its unit.

Comment thread lib/fluxter.ex
end

def write(measurement, tags, fields) when is_list(fields) do
def write(measurement, tags, fields, timestamp_milli_secs) when is_list(fields) do

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hauleth is right—we need to have a default value, otherwise all existing code will be broken.

Comment thread lib/fluxter/packet.ex
fields = encode_fields(fields)
[header, encode_key(name), tags, ?\s, fields]

case is_nil(unix_timestamp_ms) do

@lexmag lexmag Feb 6, 2018

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if would be more expressive in this case.

@feld

feld commented Mar 10, 2023

Copy link
Copy Markdown

edited:

I've played around with this too and you can get a nanosecond timestamp with System.os_time()

I think it makes the most sense to require passing through a nanosecond timestamp from the client

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants