Skip to content

[DBMON-6805] Add DBMS class attribute to DatabaseCheck#24297

Open
eric-weaver wants to merge 2 commits into
masterfrom
eric.weaver/DBMON-6805-databasecheck
Open

[DBMON-6805] Add DBMS class attribute to DatabaseCheck#24297
eric-weaver wants to merge 2 commits into
masterfrom
eric.weaver/DBMON-6805-databasecheck

Conversation

@eric-weaver

Copy link
Copy Markdown
Contributor

What does this PR do?

Adds an explicit DBMS class attribute to the base DatabaseCheck class and makes the
dbms property prefer it:

  • DBMS: str | None = None — the authoritative DBM platform identifier (e.g. "postgres",
    "sqlserver") that integrations declare on their check class.
  • The dbms property returns DBMS when set, and otherwise falls back to the existing
    class-name derivation (self.__class__.__name__.lower()). The fallback now logs a one-time
    deprecation warning so integrations that haven't declared DBMS are easy to spot.

This is intentionally non-breaking: behavior is unchanged for any check that doesn't set
DBMS, so nothing regresses until integrations opt in.

Motivation

The dbms value is the DBM platform identifier used across DBM event payloads, metric name
prefixes, and async jobs. Deriving it from the class name is unreliable — it only produces the
correct value for some integrations (e.g. PostgreSqlpostgresql and ClickhouseCheck
clickhousecheck are both wrong), which has already forced ad-hoc property overrides and a
sprawl of hardcoded "dbms" string literals throughout the DBM integrations.

This PR lays the groundwork to fix that: it introduces a single, explicit place for each
integration to declare its identifier. Follow-up PRs will set DBMS on each DatabaseCheck
subclass and route the scattered string literals through the dbms property, after which the
deprecated name-derivation fallback can be removed.

Review checklist (to be filled by reviewers)

  • Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
  • Add qa/required if this PR needs QA validation, or qa/skip-qa if it does not. Exactly one of the two is required.
  • If you need to backport this PR to another branch, you can add the backport/<branch-name> label to the PR and it will automatically open a backport PR once this one is merged

@datadog-prod-us1-6

datadog-prod-us1-6 Bot commented Jul 1, 2026

Copy link
Copy Markdown

Pipelines  Tests  Code Coverage

Fix all issues with BitsAI

⚠️ Warnings

🚦 2 Pipeline jobs failed

PR All | test / jf4d06ee / IBM MQ on Linux   View in Datadog   GitHub Actions

Validate repository | Run Validations / Validate   View in Datadog   GitHub Actions

ℹ️ Info

No other issues found (see more)

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
Patch Coverage: 71.43%
Overall Coverage: 88.00% (-0.02%)

Useful? React with 👍 / 👎

This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 02712fa | Docs | Datadog PR Page | Give us feedback!

@eric-weaver eric-weaver marked this pull request as ready for review July 1, 2026 20:44
@eric-weaver eric-weaver requested a review from a team as a code owner July 1, 2026 20:44
@dd-octo-sts

dd-octo-sts Bot commented Jul 1, 2026

Copy link
Copy Markdown
Contributor

Validation Report

Validation Description Status
qa-label Validate the pull request declares whether it needs QA for the next Agent release

Run ddev validate all changed --fix to attempt to auto-fix supported validations.

Passed validations (20)
Validation Description Status
agent-reqs Verify check versions match the Agent requirements file
ci Validate CI configuration and code coverage settings
codeowners Validate every integration has a CODEOWNERS entry
config Validate default configuration files against spec.yaml
dep Verify dependency pins are consistent and Agent-compatible
http Validate integrations use the HTTP wrapper correctly
imports Validate check imports do not use deprecated modules
integration-style Validate check code style conventions
jmx-metrics Validate JMX metrics definition files and config
labeler Validate PR labeler config matches integration directories
legacy-signature Validate no integration uses the legacy Agent check signature
license-headers Validate Python files have proper license headers
licenses Validate third-party license attribution list
metadata Validate metadata.csv metric definitions
models Validate configuration data models match spec.yaml
openmetrics Validate OpenMetrics integrations disable the metric limit
package Validate Python package metadata and naming
readmes Validate README files have required sections
saved-views Validate saved view JSON file structure and fields
version Validate version consistency between package and changelog

View full run

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants