[ https://issues.jboss.org/browse/TEIID-2584?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-2584: ------------------------------------- Continuing the discussion from the TEIID-2578, where I got still struck is Teiid has two different implementations for materialization internal and external, which are totally different. What I was thinking is we need to bring these two scenarios under same management of loading, refreshing, updating etc. In this scenario the only difference would be, if the user opted for external materialization, the call would be delegated to translator that is supporting the source table, for internal materialization have known internal translator which backed by something similar to current global temp table logic. To support creation of table(s) in this case, I thought I would need to first add the metadata addition facilities from TEIID-2578. But, I see I could amend the metadata at VDB deploy time to fit the needs internal materialization with out need for TEIID-2578. For this I would opt as you suggested to use extension metadata over Hibernate code generation, as that would not satisfy the requirements. I think we still need to leave the "creation of table" task to the user, we could either log the schema details (DDL) for materialization tables at deploy time, or leave it upto the tooling to provide hook to gather those up from extension metadata. That leaves with creation of "Status" table, we could select one of materialization targets for this and generate schema. To begin with, I do not need to modify any internal matview stuff, just barrow the logic from it, when complete, do the switch over with internal translator. I think this is close to what you are saying, may be not including the internal mat view stuff. -- 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