dj.Diagram crashes (KeyError) on PostgreSQL when node names fall back to raw table names

[dimitri-yatsenko]

Summary

dj.Diagram(...).make_dot() raises a KeyError on the PostgreSQL backend whenever a node's name cannot be resolved to a class name and falls back to the raw, quoted full table name (e.g. "schema"."table"). Instead of rendering with the table name as the label, it crashes.

Repro

import datajoint as dj
dj.config["database.backend"] = "postgresql"
schema = dj.Schema("djtest_diag")

@schema
class A(dj.Manual):
    definition = "a_id : int32"

# Empty context => class-name resolution fails => nodes keep raw table names
dj.Diagram(schema, context={}).make_dot()

KeyError: 'djtest_diag"."a'

(Any path where lookup_class_name returns None triggers it — e.g. tables not in the accessible namespace, some virtual-module / spawned-class scenarios. MySQL happens to escape it because its backtick quoting survives the strip('"') normalization; PostgreSQL's double quotes do not.)

Cause

In Diagram.make_dot (src/datajoint/diagram.py), the schema-mapping and node-styling code assumes node keys are class names (or normalize cleanly under strip('"')). When a node stays a raw PostgreSQL full table name "schema"."table", the strip-and-relookup mismatches the encapsulated key, so schema_modules[...] / node_props[name] raises KeyError.

Expected

A diagram should still render when class names can't be resolved — using the (table) name as the label — on both backends, rather than crashing on PostgreSQL.

Notes

• Pre-existing; found while adding the diagram style-regression fixture in dj.Diagram: modernize the rendered style, and fix the edge-weight rule #1532 (the fixture works around it by passing an explicit context).
• The master↔part detection in the same method was made naming-scheme-robust in the dj.Diagram: modernize the rendered style, and fix the edge-weight rule #1532 branch; the schema-map / node-props lookups still need the same treatment.