Closed DanCardin closed 2 months ago
Changes Missing Coverage | Covered Lines | Changed/Added Lines | % | ||
---|---|---|---|---|---|
src/sqlalchemy_declarative_extensions/dialects/postgresql/view.py | 60 | 61 | 98.36% | ||
src/sqlalchemy_declarative_extensions/view/base.py | 63 | 65 | 96.92% | ||
<!-- | Total: | 136 | 139 | 97.84% | --> |
Totals | |
---|---|
Change from base Build 9070561393: | -0.02% |
Covered Lines: | 2504 |
Relevant Lines: | 2583 |
Refactors out the notion of dialect-specific view classes that can contain dialect-specific view behaviors. This moves the handling of PGView and PGMaterializedView adapters from alembic_utils to that postgres dialect definition.
Using the
@view
decorator should work identically before/after this change. However, note this deprecates the use ofmaterialized
andconstraints
through direct construction of a genericView
instance. Instead, you should directly construct the dialect-specific variant (of whichsqlalchemy_declarative_extensions.dialects.postgresql.View
is the only one currently).The primary addition of this PR is an optional
materialized=MaterializedOptions(with_data=False)
variant of defining materialized views.Fixes https://github.com/DanCardin/sqlalchemy-declarative-extensions/issues/60
I had considered a
MaterializedView
variant instead of theMaterializedOptions
attribute, but it unsatifactorily messed with typing and the whole comparison system. The marginal UX difference in either direction (imo) is small enough that the much simpler implementation was worth it.