Support for materialization = view

[bdeboe]

In the current dbt-iris release, when using materialization = view, it's in fact generating tables that are fully materialized. This was due to some limitations or inconveniences in the IRIS version at that time, but I believe the acute ones have been addressed and we have a customer that really needs the view option because of dataset size.

Happy to sort out any remaining wrinkles and collaborate on a solution.

[bdeboe]

Hi @daimor ,
I'm poking around with a simple approach to add support for this in my fork, but wanted to know if there are any expected unit test failures that I can safely ignore. These don't feel related to what I'm trying:

• \tests\functional\basic\test_simple_reference.py::test_simple_reference
• \tests\functional\shared_tests\test_concurrency.py::TestConcurrency::test_concurrency

[daimor]

Hi, that's great,
I'll try to find time to look at it
as far as I remember, the most issues were with renaming views, or columns in the view

[bdeboe]

I think I have the test_simple_reference case covered now, but find the test suite a little hard to navigate, so I'm not sure whether there are tests on renaming columns that are now passing, or they're still silently skipped from the parent project.

FWIW, I'm taking a rather blunt approach to renaming views, just recreating them as needed. That hasn't appeared to cause any trouble with cascaded fallout so far, but again I'm not sure whether I need to un-skip more tests from the parent project.

[daimor]

check out views branch
it fails mostly at rename

AS expected, IDENTIFIER (rename) found ^ alter view "test17338394554585243025_test_concurrency"."view_model__815b4eb7983b46038e85b1de28b6b559" rename>

SQL for rename defined in macros rename_relation

[bdeboe]

IRIS doesn't support an ALTER VIEW v RENAME ... command (and has no intent to add that), so the approach I took in my fork is to drop and recreate, after reading the view definition query from the dictionary tables. That seems to work (also after marking views as renamable, having found the trick in your branch), with the exception of that concurrency test, which I still don't quite understand.

[daimor]

I also found an issue with this test, and as far as I got, there is something to do with cascade drop, and/or clearing cache. Need to find out how to refresh cache. When the second create of table_a happens, it thinks that it's still exists. And only happens when view used instead of table

[bdeboe]

Ha, this is the pre-existing problem that ALTER TABLE t RENAME tt fails when there are views referring to t. Let me check with development where that stands and what options we'd have to work around it without requiring an IRIS server change.

[daimor]

@bdeboe
looked again at this, and found one more thing

This sequence of queries leads to an error <View's class not found, or class type of class 'User.swappable' is not 'view'>

drop table if exists "swappable" cascade;
drop table if exists "base" cascade;
create table "base" ("name" varchar(16));
insert into "base" ("name") values ('test');
create view "swappable" as select * from "base";
drop view "swappable" cascade;
create table "swappable" as select * from "base";
drop table if exists "base" cascade;

it seems to happen, due to couple of values left after dropping view

^oddEXTR("User.base","spec",95,"User.swappable")
^oddEXTR("User.base","spec",97,"User.swappable")

[bdeboe]

@daimor thanks for reporting this. I filed a bug report internally.
the other issue with ALTER TABLE t RENAME .. had been queued up after some other work, but is now in progress.