Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relationship tests rendering in docs on the to model instead of the model the test was defined in #181

Closed
1 of 5 tasks
mascah opened this issue Mar 19, 2021 · 4 comments · Fixed by #183
Closed
1 of 5 tasks

Comments

@mascah
Copy link
Contributor

mascah commented Mar 19, 2021

Describe the bug

A clear and concise description of what the bug is. What command did you run? What happened?

relationships tests are rendering on the to model docs instead of the model that the test was defined in.

Steps To Reproduce

In as much detail as possible, please provide steps to reproduce the issue. Sample data that triggers the issue, example model code, etc is all very helpful here.

  1. dbt init a new project
  2. add a relationship test to the example my_second_dbt_model.sql
version: 2

models:
    - name: my_first_dbt_model
      description: "A starter dbt model"
      columns:
          - name: id
            description: "The primary key for this table"
            tests:
                - unique
                - not_null

    - name: my_second_dbt_model
      description: "A starter dbt model"
      columns:
          - name: id
            description: "The primary key for this table"
            tests:
                - unique
                - not_null
                - relationships:
                    to: ref('my_first_dbt_model')
                    field: id
  1. dbt docs generate
  2. dbt docs serve

image

Expected behavior

A clear and concise description of what you expected to happen.

The relationship test renders in the model that the test was defined in. Otherwise, if I have a table that has foreign keys in many other tables (i.e. date dimension), they will all show up on the date dimension, which isn't as useful as if the foreign key relationship showed in the model it was defined in, i.e. a fact table.

The current behavior is also unusual since foreign keys in a traditional RDBMS are defined on the the foreign table pointing to the parent table, whereas now in the docs the parent table is pointing to all of the child tables.

Screenshots and log output

If applicable, add screenshots or log output to help explain your problem.

System information

Which database are you using dbt with?

  • postgres
  • redshift
  • bigquery
  • snowflake
  • other (specify: ____________)

The output of dbt --version:

dbt --version
installed version: 0.19.0
   latest version: 0.19.0

Up to date!

Plugins:
  - bigquery: 0.19.0
  - snowflake: 0.19.0
  - redshift: 0.19.0
  - postgres: 0.19.0

The operating system you're using:

macOS 10.15.6

The output of python --version:

3.8.1

Additional context

Add any other context about the problem here.

@mascah mascah closed this as completed Mar 19, 2021
@mascah mascah changed the title Relationship tests not rendering in docs Relationship tests rendering in docs on the to model instead of the model the test was defined in Mar 19, 2021
@mascah mascah reopened this Mar 19, 2021
@jtcohen6
Copy link
Contributor

@mascah Thanks for opening! I agree, this is weird. The relationship is from my_second_dbt_model (foreign/child/"many" table) to my_first_dbt_model (parent/"one" table).

From mucking around with this locally, it does appear that the relationships test will indeed not render (as your issue originally stated) if the names of the child column and parent (field:) differ. Weird!

In any case, I believe the fix for this would need to come in the dbt-docs codebase, since all the requisite information is available in the manifest. I'm going to transfer this issue over there.

@jtcohen6 jtcohen6 transferred this issue from dbt-labs/dbt-core Mar 22, 2021
@jtcohen6
Copy link
Contributor

For anyone interested in giving this a go, I think this is the right place to start poking:
https://github.com/fishtown-analytics/dbt-docs/blob/97570c58c474dfbba0b145576792bc8e3ead6c5c/src/app/services/project_service.js#L172-L179

@mascah
Copy link
Contributor Author

mascah commented Mar 23, 2021

For anyone interested in giving this a go, I think this is the right place to start poking:
https://github.com/fishtown-analytics/dbt-docs/blob/97570c58c474dfbba0b145576792bc8e3ead6c5c/src/app/services/project_service.js#L172-L179

I'm going to try and play around with this, but I have a curiosity question about the best way to go about doing that.

I'm not sure I exactly understand how the core dbt project runs/references this code when I run dbt docs generate. I can't seem to find any *.js when I try to run a find in the directory where brew installed dbt.

I figure I could just clone this project and play with it from there to get a better understanding of how to make this change, but my curiosity is getting the better of me regarding where this code lives relative to the core dbt project.

@jtcohen6
Copy link
Contributor

jtcohen6 commented Mar 23, 2021

Fair question! This repository contains all the JS code that powers the static documentation site. When it's ready to ship—i.e., before we release a new version of dbt—we minify the JS in this repo and package it (together with all the HTML) into a single file, index.html, which is then updated here.

E.g. #157 fixed a dbt-docs bug, and then we shipped it via a dbt PR here: dbt-labs/dbt-core#2965

In order to test changes to this repository in development, you can follow the instructions in the README.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants