[teiid-dev] Materialized Views

All, Teiid Designer 7.1 is targeted to restore some notion of Materialized Views. The MMX solution created the materialized tables within the VDB based on the "isMaterialized" property for each virtual table. The user had no other control of these "tables" during design-time. For Teiid Designer, we chose to expose Materialization in a different way by allowing users to create Physical models representing the Materialized structure of virtual tables. So the new use-case is: 1) User selects one or more "virtual" tables in a virtual model 2) Right-click select "Modeling > Create Materialized Views" action 3) Selecting existing physical model (or schema within that model) or Create new physical relational model. 4) Each "virtual table" has it's "isMaterialized" property set to TRUE and a "soft-reference" to the new "materialized" physical table is stored with the virtual table. 5) During build time, this "materializedView" reference UUID is set on the proper INDEX entry for the virtual table. 6) Since the "materialized" model is just a physical model, this model is indexed just like all other XMI files and if added to a VDB, its metadata is available just like any other model. 7) Note that in MMX, the Materialization model created in the VDB was a relational model with a "Materialization" model type, and not actually a Physical model. We're dropping the notion of a "Materialization" model type. The scenario above, is basically coded and working. The catch is that Designer's Relational and Transformation metamodels do not account for a "Materialized Table" reference on the virtual table EObject. For those of you who know about EMF, it can be a big deal to change our metamodel to accomodate this reference. Without that metamodel change, Designer won't automatically detect the additional virtual model dependency, a new "model import" entry won't be created AND when adding the Virtual model to a VDB, the "Materialization" physical model won't automatically get added. That all said, would it be wrong to NOT treat these Materialization Physical models as dependencies? Users would be totally responsible for including them in a VDB containing the original virtual models? Comments, ideas? Barry