feat/data-query-metrics adds vaadin.data.fetch.rows and vaadin.data.fetch.requested, measured at the data provider layer. vaadin.db.fetch.rows measures at the JDBC layer, requires DataSource proxying, and is opt-in behind vaadin.observability.database.
The two now overlap substantially and the names are almost identical. The data provider meter covers the common "which view reads too much" case, works for non-JDBC data providers, and needs no proxying.
Decide before both ship in 5.0
- Keep both, with documentation making clear when each applies.
- Or demote
vaadin.observability.database further.
- Or drop the JDBC row counting and keep
vaadin.db.query for per query spans only.
Shipping two near-identically named row count summaries with different capture points is the outcome to avoid.
feat/data-query-metricsaddsvaadin.data.fetch.rowsandvaadin.data.fetch.requested, measured at the data provider layer.vaadin.db.fetch.rowsmeasures at the JDBC layer, requiresDataSourceproxying, and is opt-in behindvaadin.observability.database.The two now overlap substantially and the names are almost identical. The data provider meter covers the common "which view reads too much" case, works for non-JDBC data providers, and needs no proxying.
Decide before both ship in 5.0
vaadin.observability.databasefurther.vaadin.db.queryfor per query spans only.Shipping two near-identically named row count summaries with different capture points is the outcome to avoid.