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

Add event support #4

Merged
merged 13 commits into from
Sep 19, 2014
Merged

Add event support #4

merged 13 commits into from
Sep 19, 2014

Conversation

andrei-m
Copy link
Contributor

Implements code review feedback from #2

@andrei-m
Copy link
Contributor Author

Thank you @mkobetic for the original contribution! @mkobetic @sidgopalan would appreciate your feedback.
I referenced the DataDog Ruby client implementation for a few things, particularly the 8KB event size limit: DataDog/dogstatsd-ruby#5

I just noticed #3 as well. Looks like you have your choice of pulls for this feature 😛

AlertType: alertType,
Tags: tags,
}
// Use the given client namespace as the source type name, if given
Copy link
Contributor

Choose a reason for hiding this comment

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

Hm, why did you decide to move this here. Given that this function is private, any client wishing to use the extended Event API, will miss this additional processing. Is that intentional?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The intent is to give clients that use Event full control, but I see what you mean about missing out on the default namespace-based SourceTypeName if it's left empty on the struct. My first inclination is to modify Event(...) to use EventOpts.SourceTypeName if it's not empty and otherwise fallback to the Client.Namespace behavior. A possible problem is that this leaves no way for the client to omit SourceTypeName from the message entirely. Is that something we care about?

Copy link
Contributor

Choose a reason for hiding this comment

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

That sounds reasonable, I think what you want to avoid more is not having any source info, whether from the client or from the API call.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK, makes sense. I'll plan to get another pull in that does that within the next week or so.

@mkobetic
Copy link
Contributor

Otherwise LGTM. Thanks!

@sidgopalan
Copy link
Contributor

Looks great. Thanks @andrei-m and @mkobetic for the contribution. I'll get this merged in today.

sidgopalan added a commit that referenced this pull request Sep 19, 2014
@sidgopalan sidgopalan merged commit f093b1f into ooyala:master Sep 19, 2014
@sidgopalan sidgopalan mentioned this pull request Sep 19, 2014
}
func (c *Client) Event(title string, text string, eo *EventOpts) error {
var b bytes.Buffer
fmt.Fprintf(&b, "_e{%d,%d}:%s|%s|t:%s", len(title), len(text), title, text, eo.AlertType)

Choose a reason for hiding this comment

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

Do we know if datadog wants the byte length of title and text or the character length? If the latter this should be len([]rune(title))

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catch! The documentation isn't specific about this, but the official Ruby implementation strongly suggests this should be character length. The code uses string#length, which returns character rather than byte length. I'll open another pull with a fix.

Copy link
Contributor

Choose a reason for hiding this comment

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

In that case I'd use http://golang.org/pkg/unicode/utf8/#RuneCountInString, rather than copying the string into a []rune.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Agreed: #5

@andrei-m andrei-m deleted the add_events branch September 19, 2014 19:59
@mkobetic
Copy link
Contributor

Thanks @sidgopalan! I apologize for dropping the ball on the review response, and I'm grateful to @andrei-m for stepping in.

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.

None yet

4 participants