fix(ingest/teradata): lowercase database container URNs under convert_urns_to_lowercase

[treff7es]

Summary

When convert_urns_to_lowercase is enabled, the Teradata connector lower-cased dataset URNs — via get_identifier() and the central AutoLowercaseUrnsProcessor — but built the database container URN from the source-case name. This split one physical database into two URN identities: datasets were parented under a container whose key did not match their own (lower-cased) name.

Because a container URN is an opaque hash of its key, the stream-level AutoLowercaseUrnsProcessor (which only rewrites dataset/schemaField URNs) structurally cannot fix container casing — it has to be normalized at key-build time in the source. This mirrors how Snowflake already handles it (routing the database/schema name through snowflake_identifier before gen_database_key/gen_schema_key).

Changes

• Add _maybe_lower_urn_name() helper and apply it in the two seams that build the database container key:
  • get_database_container_key() — dataset → container parenting
  • gen_database_containers() — container entity creation
• get_db_name() is intentionally left in source case: it is reused verbatim as a quoted SQL identifier (DATABASE "{schema}" set before view HELP commands), which must match the stored case in CASESPECIFIC installations. Only URN identity is normalized; SQL resolution is unaffected.

Behavior

• Default config (convert_urns_to_lowercase: false) is unchanged.
• With the flag enabled, container URNs are now consistent with the (already lower-cased) dataset URNs.

Testing

• TestConvertUrnsToLowercaseContainerConsistency: flag-on consistency, flag-off no-op, and that the container creation and parenting paths resolve to the same container URN.
• Full Teradata unit suites pass; ruff + mypy clean.

Checklist

• The PR conforms to DataHub's Contributing Guideline (particularly PR Title Format)
• Tests for the changes have been added/updated
• Breaking change documented in docs/how/updating-datahub.md

Note: this is a URN-changing migration for deployments already running with the flag enabled (their container URNs shift from source-case to lower-case on the next run). See the entry added to docs/how/updating-datahub.md.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

📢 Thoughts on this report? Let us know!

[skrydal]

Comment like this is quite dangerous, it describes places which this function is called from, which function itself has no control over.

[treff7es]

Trimmed — the comment no longer references the other call paths, it just states the local reason (normalize the name so the container URN matches the dataset URNs). Did the same for the sibling comments.

[skrydal]

LGTM, comments are overly verbose though.

Do I understand correctly, that if user actively uses Teradata's capability to have 2 different databases differing by casing (e.g. Foo and foo) we will generate a single container for them if lowercasing is enabled? Effectively lowercase flag can be used only by users who can ensure they do not have such cases in their data source?

[treff7es]

@skrydal on the casing question: for Teradata specifically this can't happen — object identifiers (database/table names) are case-insensitive, so you can't have two databases differing only by case (CASESPECIFIC only affects CHAR data comparison, not names). More generally the caveat isn't new to this PR: with convert_urns_to_lowercase on, the datasets under such names already collapse to a single URN via get_identifier()/AutoLowercaseUrnsProcessor — this change just makes the container consistent with the datasets it already parents.

Also trimmed all the comments per your note.