-
Notifications
You must be signed in to change notification settings - Fork 44
Description
For models materialized as tables, the rows_affected property in run_results.json is always set to -1 instead of the actual number of rows inserted.
I think this may be due to a combination of how the call statements are organized in the table materialization and how results are extracted when there are multiple result sets per call.
In the table materialization code, call statement('main') is wrapped around a call to the create_table_as macro. This macro first creates a temp view and then executes either insert into...select or create table as select. In either case, the statement that would return the correct row count is the second statement in the call.
In fabric_connection_manager.py, in the execute function, the code appears to select the first result set from the executed statement. My theory is the adapter is reading the row count from the create temp view statement instead of the statement that inserts into the table (but I can't explain why the value is -1 instead of 0).
I tried some code where only the create table as select statement is wrapped by the call statement('main') statement, and it appears to set rows_affected correctly. But I don't know if it would be better to refactor the macros to adjust the call statement('main') blocks, or to change fabric_connection_manager.py. I will point out, though, that the dbt docs say that rows_affected should be the "number of rows modified by the last statement executed "), which doesn't appear to be the case with the fabric adapter.