-
Notifications
You must be signed in to change notification settings - Fork 3
[Bug] Refer to business_account table instead of account #12
Description
Is there an existing issue for this?
- I have searched the existing issues
Describe the issue
This fusion issue uncovered that we are referring to an outdated version of the account table.
As we see in the ERD, it's now called business_account. It has all the columns we currently include in the staging account model. The ERD does not include currency; however, I do see it in internal Reddit datasets, so I think we should still include it (we have our column-filling macro as backup)
This likely did not cause an issue before due to how our unioning macro works, on top of some folks still having the old account table.
Relevant error log or model output
Expected behavior
We should reference the existing table and get non-null account records.
Possible solution
The question here is how much we want to change to business_account.
For example, in the src file, we definitely need to adjust the default identifier value, but do we want to change the name of the source node from account to business_account? If so, we'll need to adjust the value of this variable (and do we want to change the variable name?)
Moreover, do we want to update the staging model names to reflect business_account, or keep the update as seamless as possible for downstream transformations?
Also, please keep the union_data macro and arguments in mind.
dbt Project configurations
NA
Package versions
latest
What database are you using dbt with?
postgres, redshift, snowflake, bigquery, databricks
How are you running this dbt package?
other (mention it in "Additional Context"), dbt Cloud™
dbt Version
latest
Additional Context
No response
Are you willing to open a PR to help address this issue?
- Yes.
- Yes, but I will need assistance.
- No.
