[ https://issues.jboss.org/browse/TEIID-2584?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2584: --------------------------------------- Can we also remove or change the property form of MATERIALIZED_TABLE (which can be determined from the materialized_views table) and the UPDATE_COUNT? The fewer "med" properties we natively rely on the better. For the triggers table, see the system tables in oracle/pg. You'd likely have columns: schema, table, trigger body, trigger type (INSTEAD OF), triggering event (INSERT/UPDATE/DELETE), status (ENABLED/DISABLED) common stuff - which we currently don't track as we aren't creating a proper metadata record: name, description, uid Yes, the refresh procedure looks about right (With an atomic block and dynamic sql for the delete/select that should do the trick). We should allow a variation of that to work against internal materialized views as well. We can leave off manipulations to the cache hint then. Another open issue seems to be that the engine does not have a built-in way to react to the mat view status. If the status is something other than loaded/valid, then we should likely have a configurable outcome - ignore, error, wait?, refesh?, etc. -- 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