using transformation_id instead of event_subtype`

CHANGELOG.md

@@ -1,7 +1,7 @@
 # dbt_fivetran_log v0.5.4
 ## Fixes
 - The unique combination of columns test within the `fivetran_log__schema_changelog` model has been updated to also check the `message_data` field. This is needed as schema changelog events may now sync at the same time. ([#51](https://github.com/fivetran/dbt_fivetran_log/pull/51))
-- The `fivetran_log__connector_status` model has been adjusted to filter out all `TRANSFORMATION` event_subtype logs. Transformation logs are not always synced as a JSON object and thus the package may encounter errors on Snowflake warehouses when parsing non-JSON fields. Since transformation records are not used in this end model, they have been filtered out. ([#51](https://github.com/fivetran/dbt_fivetran_log/pull/51))
+- The `fivetran_log__connector_status` model has been adjusted to filter out all logs that contain a `transformation_id`. Transformation logs are not always synced as a JSON object and thus the package may encounter errors on Snowflake warehouses when parsing non-JSON fields. Since transformation records are not used in this end model, they have been filtered out. ([#51](https://github.com/fivetran/dbt_fivetran_log/pull/51))
 # dbt_fivetran_log v0.5.3
 ## Fixes
 - Per the [Fivetran Log December 2021 Release Notes](https://fivetran.com/docs/logs/changelog#december2021) every sync results in a final `sync_end` event. In the previous version of this package, a successful sync was identified via a `sync_end` event while anything else was a version of broken. Since all syncs result in a `sync_end` event now, the package has been updated to account for this change within the connector.

models/fivetran_log__connector_status.sql

@@ -2,7 +2,7 @@ with transformation_removal as (
 
     select *
     from {{ ref('stg_fivetran_log__log') }}
-    where event_subtype != 'TRANSFORMATION'
+    where transformation_id is null
 
 ),