GitHub user binarycat-dremio created a discussion: [DISCUSS] FlightSQL tracing:
expected relationship between Open, statement/query spans, and connection-level
correlation
Hi team,
I'd like to clarify the intended tracing model for ADBC FlightSQL.
In a typical DB-API flow like:
```python
with dbapi.connect(...) as conn:
with conn.cursor() as cur:
cur.execute(sql1)
cur.fetchall()
cur.execute(sql2)
cur.fetchall()
```
there seem to be a few possible interpretations of how tracing should behave,
and I'm not sure which one is the expected design.
Questions:
1. Should all query-related spans created from a single connection be grouped
under the `FlightSQLDatabase.Open` span/trace?
2. Or should each statement / `execute(...)` operation start its own logical
trace?
3. If query operations are intentionally separate, is the preferred correlation
mechanism something like a stable `connection_id` attribute on statement/cursor
spans rather than parent-child trace linkage?
>From an observability perspective, I can see two reasonable models:
- Connection-oriented model: `Open` is the parent context, and later `Prepare`
/ `ExecuteQuery` spans for that connection are grouped beneath it.
- Query-oriented model: each logical query execution gets its own trace/span
tree, and cross-query correlation happens through attributes such as
`connection_id`.
I'm mainly trying to understand the intended behavior before proposing any
broader change.
Related:
- Issue: https://github.com/apache/arrow-adbc/issues/4568
- PR: https://github.com/apache/arrow-adbc/pull/4570
GitHub link: https://github.com/apache/arrow-adbc/discussions/4572
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to: [email protected]
