docs(csharp/src/Drivers/Databricks): Client Telemetry Design#3636
docs(csharp/src/Drivers/Databricks): Client Telemetry Design#3636jadewang-db wants to merge 7 commits intoapache:mainfrom
Conversation
Signed-off-by: Sreekanth Vadigi <sreekanth.vadigi@databricks.com>
csharp/src/Drivers/Databricks/Telemetry/telemetry-activity-based-design.md
Outdated
Show resolved
Hide resolved
csharp/src/Drivers/Databricks/Telemetry/telemetry-activity-based-design.md
Show resolved
Hide resolved
| /// <summary> | ||
| /// Tag definitions for Connection.Open events. | ||
| /// </summary> | ||
| internal static class ConnectionOpenEvent |
There was a problem hiding this comment.
I am trying to think if this is the best long term apporach to have each event be a separate class.
Currently the events are pretty free-formed and sometimes it is used to designate the start/end of an operation like: db.operation.cancel_operation.starting, db.operation.cancel_operation.end.
If the event name grows there probably is a big overhead. The alternative is to move all the events into a isngle class file and starts from there. Then it means the event and tags can be mixed together, the tag can belong to any event and event can contain any tag. this kind of give us another level of freedom and avoid defining duplicate tags in the future.
There was a problem hiding this comment.
I would say think of this as the generated code such as thrift protocol. and just follow the json schema design, easy of use should be the main purpose.
unless we want to make the telemetry json schema more generic, but this will need bigger change and should be out of the scope of this work
There was a problem hiding this comment.
Talked offline, there should not be too many event type name, let's just stick to this for now
No description provided.