[ https://issues.jboss.org/browse/TEIID-2578?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2578: --------------------------------------- My initial comments are based off of the title, which implies runtime manipulation of Teiid schema entries. That in and of itself is a feature and if possible via a translator should be exposed via statements. Maybe it would help to clarify the flow for materialization metadata. Here are three scenarios: 1. The current internal approach. The view metadata only is known to Teiid and we create an internal "global" materialized temporary table based upon the metadata. The temporary table is not explicitly part of any Teiid schema and can only be referenced through the materialized view and through admin procedures. 2. The current external approach. The view metadata is known to Teiid but it must also reference another table that is presumed to contain the materialized results - we do not know how the Teiid metadata entry was created or how the corresponding source materialized table was created. 3. What I think you're pursuing. The view metadata only is known to Teiid but the view must also reference a source on which to materialize. From here we must fill in all the details of how the source materialized table is created and what metadata Teiid uses to represent it. Related to creating Teiid schema entries, if we follow the approach of #1 then there is no need to alter Teiid schema's at runtime. So to clarify I'd like to: * decouple the notion of adding schema entries from materialization. * start with the most simplistic approach to 2/3 by offing the ability to create a materialization model (similar to the old MMX approach which can be done somewhat like the Hibernate temp logic). This would be generated either at or before deploy time and obviates the need to alter Teiid schemas at runtime. From there the real meat of the issue is TEIID-2584. For example as mentioned above if we want to offer the ability to manage and tweak the ddl that could be done via extension metadata - for any high-end usage no one will rely on auto generated ddl since they will need to fill in details such as the tablespace, alternative index types (hash, bitmap), additional columns for incremental update, etc. TEIID-2584 is also complicated by source permissions at least in terms of creation - that was side-stepped by MMX and not a concern with the internal logic. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira