-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Expose LogEntry.operation
#1676
Comments
Do you plan on implementing an |
Dunno. An operation is conceptually a If we wanted to expose it as a wrapper around Hmm, maybe we should add a helper for |
It doesn't seem like it should derive from |
I think the two are unrelated: in Bigtable, the operation is defined by the API. For logging, the operation is defined (optionally) by the |
Ahh gotcha. |
Hello, As part of trying to get things under control (as well as to empower us to provide better customer service in the future), I am declaring a "bankruptcy" of sorts on many of the old issues, especially those likely to have been addressed or made obsolete by more recent updates. My goal is to close stale issues whose relevance or solution is no longer immediately evident, and which appear to be of lower importance. I believe in good faith that this is one of those issues, but I am scanning quickly and may occasionally be wrong. If this is an issue of high importance, please comment here and we will reconsider. If this is an issue whose solution is trivial, please consider providing a pull request. Thank you! |
Remaining feature from #1566.
Open question: should the
operation
field be just-another-metadata-field (likeseverity
,http_request
), or should we expose it via some convenience wrapper (e.g., as an optional field onBatch
, or some other context manager)?The text was updated successfully, but these errors were encountered: