Customising labels in outputs

[dsmdavid]

I'm not sure if this is possible already or not, I just haven't found a way of doing it.

I think it would be useful to be able to customise the labels created in the diagrams. Sometimes the names may be too long and clutter the diagram, and the relationships do not show a concept, but rather the name of the columns checked.

e.g. original

erDiagram
 
  "MODEL.DBT_RESTO.DIM_PRIZE" {
    varchar prize_key
    nvarchar prize_name
    int prize_order
  }
  "MODEL.DBT_RESTO.FACT_RESULT" {
    varchar fact_result_key
    varchar box_key
    varchar prize_key
    date date_key
    int no_of_won
    float prize_value
    float prize_paid
    int is_prize_taken
  }
  "MODEL.DBT_RESTO.DIM_PRIZE" ||--o{ "MODEL.DBT_RESTO.FACT_RESULT": prize_key

Loading

with modified labels:

erDiagram
 
  "MODEL.DBT_RESTO.DIM_PRIZE"["dim_prize"] {
    varchar prize_key
    nvarchar prize_name
    int prize_order
  }
  "MODEL.DBT_RESTO.FACT_RESULT"["fct_result"] {
    varchar fact_result_key
    varchar box_key
    varchar prize_key
    date date_key
    int no_of_won
    float prize_value
    float prize_paid
    int is_prize_taken
  }
  "MODEL.DBT_RESTO.DIM_PRIZE" ||--o{ "MODEL.DBT_RESTO.FACT_RESULT": "is part of"

Loading

In my mind this could be derived from meta properties. I'm not sure how this works for outputs other than mermaid.

[datnguye]

Thanks @dsmdavid for the good discussion here!

Firstly to confirm, no, this ability is not yet available, instead, it's using the column name to label the connector currently.

And for the solution to support the customized label of the connector, the meta config might be the way even when I am not fully convinced since it means more works to do.

Here are some of my observations / suggestions:

• ⚠️ There is a reason to use column name in the connector label, instead of, something meaningful e.g. is part of: In case that we have multiple connectors between 2 entities, it feels lost to know which A's fields connecting to which B's field. Or in case that A has single connector to B and A has the self-connector.
• 💡 We might leverage the existing meta. relationship_type and do the auto-labelling with set of pre-built options, given the sample command as dbterd run --connector-label <option>:
  • default: Using column names as implemented
  • custom-xxx: xxx can be a pre-built dict containing the mapping as follow:
    • One-to-Many (1n): "has many", "contains", "includes", "consists of", "owns"
    • Zero-to-Many (0n): "may have", "can include", "might contain", "optionally has", "could consist of"
    • Many-to-Many (nn): "associated with", "linked to", "related to", "connected to", "paired with"
    • One-to-One (11): "is linked to", "corresponds to", "matches", "is paired with", "is associated with"
    • Many-to-One (n1): "belongs to", "is part of", "is included in", "is owned by", "is contained in"
  • If we need customize xxx, set its dict to the env var

👀 Other suggestion?

We can start to build it for Mermaid first, and iterate to add for all in general later 👍

Let me know what you think! You'll be more then welcome to take action and raise PR 🙌

Cheers!

[dsmdavid]

I created a PR #130 with a potential approach - I had intended to create it as a draft for discussion 😅. What do you think?
To your points above:

There is a reason to use column name in the connector label, instead of, something meaningful e.g. is part of: In case that we have multiple connectors between 2 entities, it feels lost to know which A's fields connecting to which B's field. Or in case that A has single connector to B and A has the self-connector.

Each relationship maintains its own ability to keep its original label (based on column names) so it falls on the developer to decide whether to use the label or not (and even to include the column names if they so choose).

💡 We might leverage the existing meta. relationship_type and do the auto-labelling with set of pre-built options, given the sample command as dbterd run --connector-label

I feel this can be quite complex/limiting as different relationships with a similar relationship_type may represent different concepts.

On a more general note, not sure if it would be easier to have the whole meta available to use it during the parse by the target, in case there are any more uses for it.

Thoughts?

[datnguye]

Hi @dsmdavid

I created a PR #130 with a potential approach

It looks good to proceed with the suggested approach, so let's go with it for now. However, let's consider the auto-labeling approach in the next PRs (I might create that but uncertainty of when) because the more meta fields the more works for developers to do.

On a more general note, not sure if it would be easier to have the whole meta available to use it during the parse by the target, in case there are any more uses for it

Yep that makes sense, feel free to do that, or let me know if I need to add this to a feature wishlist 👍

Cheers!