Create-tableau-dashboard-based-on-iasworld-tests

[Damonamajor]

This is the query that I have been using to test. It seems like it gets updated pretty frequently, so although it passessed yesterday, it is failing today. Here's an example of a PIN which fails in this query, but has updated info for matching class_equals_luc: Parid 25343080220000

WITH view_rows AS (
    SELECT test_name, parid, taxyr
    FROM z_ci_1088_create_tableau_dashboard_based_on_iasworld_tests_qc.vw_report_iasworld_test_pardat
),
test_failure_rows AS (
    SELECT 'iasworld_pardat_adrno_length_lte_5' AS test_name, parid, taxyr
    FROM z_dev_damajor_test_failure.iasworld_pardat_adrno_length_lte_5
    UNION ALL
    SELECT 'iasworld_pardat_class_equals_luc', parid, taxyr
    FROM z_dev_damajor_test_failure.iasworld_pardat_class_equals_luc
    UNION ALL
    SELECT 'iasworld_pardat_cur_in_accepted_values', parid, taxyr
    FROM z_dev_damajor_test_failure.iasworld_pardat_cur_in_accepted_values
    UNION ALL
    SELECT 'iasworld_pardat_nbhd_matches_legdat_township', parid, taxyr
    FROM z_dev_damajor_test_failure.iasworld_pardat_nbhd_matches_legdat_township
    UNION ALL
    SELECT 'iasworld_pardat_nbhd_matches_spatial_town_nbhd', parid, taxyr
    FROM z_dev_damajor_test_failure.iasworld_pardat_nbhd_matches_spatial_town_nbhd
    UNION ALL
    SELECT 'iasworld_pardat_seq_all_sequential_exist', parid, taxyr
    FROM z_dev_damajor_test_failure.iasworld_pardat_seq_all_sequential_exist
    UNION ALL
    SELECT 'iasworld_pardat_unique_by_parid_taxyr', parid, taxyr
    FROM z_dev_damajor_test_failure.iasworld_pardat_unique_by_parid_taxyr
)
SELECT
    COALESCE(v.test_name, f.test_name) AS test_name,
    COALESCE(v.parid, f.parid) AS parid,
    COALESCE(v.taxyr, f.taxyr) AS taxyr,
    CASE
        WHEN v.parid IS NULL THEN 'only in old failures'
        WHEN f.parid IS NULL THEN 'only in new failures'
    END AS source
FROM view_rows v
FULL OUTER JOIN test_failure_rows f
    ON v.test_name = f.test_name
    AND v.parid = f.parid
    AND v.taxyr = f.taxyr
WHERE v.parid IS NULL OR f.parid IS NULL
ORDER BY parid, test_name

I'm not sure this is exactly the structure you wanted. It doesn't create an individual view for each of the subqueries, but that also feels like a lot to mantain, document, etc.. For me a single view makes the most sense, but happy to reconfigure it based on your feedback.

I also left out this section until we get a solid grasp on what we want

Note that there are a few scattered QC views that have iasWorld tests defined on their schema, namely qc.vw_iasworld_sales_, qc.vw_report_town_close_res_parcels_not_set_to_cost_approach, qc.vw_neg_asmt_value, and reporting.vw_pin_value_long. It would be best to try to move these tests into the qc.vw_report_iasworld_test_ view for whichever table is most important in the test, but I haven't looked at these tests in detail, so I don't have a sense of how hard that will be. In the worst case scenario, it's fine to continue using these views as the basis for the new table definitions.

It also doesn't union all iasworld views since we are only testing a single one first.

[Damonamajor]

I'm not sure this is exactly the structure you wanted. It doesn't create an individual view for each of the subqueries, but that also feels like a lot to mantain, document, etc.. For me a single view makes the most sense, but happy to reconfigure it based on your feedback.

I also left out this section until we get a solid grasp on what we want

Note that there are a few scattered QC views that have iasWorld tests defined on their schema, namely qc.vw_iasworld_sales_, qc.vw_report_town_close_res_parcels_not_set_to_cost_approach, qc.vw_neg_asmt_value, and reporting.vw_pin_value_long. It would be best to try to move these tests into the qc.vw_report_iasworld_test_ view for whichever table is most important in the test, but I haven't looked at these tests in detail, so I don't have a sense of how hard that will be. In the worst case scenario, it's fine to continue using these views as the basis for the new table definitions.

It also doesn't union all iasworld views since we are only testing a single one first.

[Damonamajor]

named like this due to sequential tests.

[Damonamajor]

We can pull the from pardat into it's own object and remove this from each query as well

        AND pardat.cur = 'Y'
        AND pardat.deactivat IS NULL

[Damonamajor]

I just did this, I think it makes it easier to follow.

[Damonamajor]

We often only need the join for township code, which should be deriveable from class, but we are also getting some errors for tests based on this. Let me know if we want this join for each. We can also move it up to the CTE.

[Damonamajor]

Do we want this in both nbhd queries, it seems only in this one and not the previous one

[Damonamajor]

We already select class as one of our base columns. Do we want it as additional too? This goes for class or township values.

[Damonamajor]

Not all of the tests have a value for meta.category

[jeancochrane]

Very nice start here! I think the fundamentals of this approach are correct, and the output looks good.

That being said, it feels to me like this implementation might end up requiring a lot of repetitive boilerplate that could become difficult to maintain, i.e. a separate subquery for each individual test that needs to select the same set of columns in the same exact way. I thought it might be interesting to factor out as much of the boilerplate as possible into a shared macro, and I ended up producing a follow-up PR implementing that approach (#1095). Take a look at that PR and let me know if you think it's prohibitively confusing; if the macro stuff is impossible to understand, I'm down to continue forward with the more boilerplate-heavy approach we have here, and only refactor to a macro approach if/when it becomes unwieldy.

[Damonamajor]

Very nice start here! I think the fundamentals of this approach are correct, and the output looks good.

That being said, it feels to me like this implementation might end up requiring a lot of repetitive boilerplate that could become difficult to maintain, i.e. a separate subquery for each individual test that needs to select the same set of columns in the same exact way. I thought it might be interesting to factor out as much of the boilerplate as possible into a shared macro, and I ended up producing a follow-up PR implementing that approach (#1095). Take a look at that PR and let me know if you think it's prohibitively confusing; if the macro stuff is impossible to understand, I'm down to continue forward with the more boilerplate-heavy approach we have here, and only refactor to a macro approach if/when it becomes unwieldy.

I'll take a look through it tomorrow, but it seems like a more efficient system.