-
Notifications
You must be signed in to change notification settings - Fork 8
devices: make LastSeen a pointer #57
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
Merged
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(non-blocking)
our own Time wrapper type was already weird, but now this is kinda double weird
doesn't json/v2 let us do omitzero + custom marshaling on a normal time.Time?
cc @dsnet
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We already support
omitzeroin v1 json.Can't we just rely on
time.Time.IsZeroto indicate thatConnectedToControlis true?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have to teach users about this API pattern in Go
Currently this is all undocumented, which is a large part of the problem, and it needs documentation that includes both what it is, what it is not, and usage guidance, as it's a big challenge for folks to understand.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's two levels of documentation, one is the actual API documentation which I think is quite clear, the other is documenting the Go API wrapper itself, which could use some work.
Educating people about Go usage patterns for zero values is definitely worth considering, but in this particular case we have a value that in practice could never used to be zero, but now can be. Turning it into a pointer is one way to emphasize that it's actually nullable from a JSON perspective.
Another pattern we could use would be something like
sql.NullTimeorsql.NullString. I went with a pointer here because we already use it on both request and response types in this library. It's particularly useful onPATCHrequests where you need to distinguish between "I want to set this value to its zero value" vs "I don't want to touch this value".There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dsnet
You're asking whether we even need the
ConnectedToControlfield or should just infer it fromLastSeenbeing empty? We went with an explicit field because it's more discoverable.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Honestly most things users use this field for are harmful and I really strongly believe we should remove it because of that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I disagree that this is clear: it provides no guidance as to when this data is appropriate to consume and for what purposes. We have a long history of users making bad choices around that, including ourselves, despite explanations as to what the data is as is in the documentation there.