dbt

Describe the bug

No option to remove invalid dashboard filters.

To Reproduce

Steps to reproduce the behavior:

1. Go to dashboard
2. Add filter
3. Manually edit fieldId in url to something invalid
4. See error

Expected behavior

• Be able to remove the filter.
• [bonus] Don't display these messages until

What type of re_data dbt macro you would like to add

• validate

What macro should be doing

Return true is string is a valid JSON and can be parsed to JSON

In this PR, I wanted to solve issue #25 by creating a CSV file to list and also help the brand property matching process. This PR including:

• Compile a list of all brand names and operator names from the name-suggestion-index as a CSV with the columns id, display_name, and wiki_data in tmp folder.
  Deadline: 05.01.2022

• Create a PySpark UDF similar to the ones in the osm

Where it makes sense, we should check inputs for datatype, length etc before processing, and if necessary raise an exception via exceptions.raise_compiler_error.
See: https://github.com/calogica/dbt-expectations/blob/b69ac04cacfe1dfaf1de129778908898e666f9e3/macros/schema_tests/multi-column/expect_compound_columns_to_be_unique.sql#L16

faldbt object already has access to the manifest; we need to pass it here in the exec method. We probably want to pass the dbt manifest directly rather than the fal wrapper as we dont want the fal wrapper to be our public api.

https://github.com/fal-ai/fal/blob/main/src/fal/dag.py#L51

I'm new to the idea of Data Vault 2.0 and I'm reading the Dan Linstedt book to understand it better.

To help me get a better perspective of how dbtvault works I would like to know how difficult do you think it would be to add support for BigQuery?

Are there specific features of Snowflake which makes it better for running dbt/dbtvault ?

Thanks,
Jacob

@mhindery asks whether we could use the binary instead as a lot of other common data engineering projects defer to it now and this forces users to use yet another package.

We will have to test it but I think it should be fine.

Initial discussion happened here:
bitpicky/dbt-sugar#20 (comment)

Other adapters (e.g. dbt-spark) have adopted a single-source-of-truth approach to documentation, prefering to document setup and configuration information only on the docs.getdbt website, rather than duplicating it on the docs page and the adapter repo's readme.

I think we should do the same.