[ https://issues.jboss.org/browse/TEIID-2578?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2578: --------------------------------------- We don't need to have extra built-in support if it's not expected. The JDBC import properties related to procedures can still be used. This doesn't sound like how it should work, unless there were some specific MERGE INTO or IMPORT IF NOT EXISTS option. Otherwise I'd expect that the action of the import would need to have the tables dropped ahead of time. Which is no different that we do today as we default to caching the source metadata after the first deployment. However we allow the user to set on the model/schema if they want it to always reload and via the adminapi allow for metadata cache to be specifically invalidated as part of reload. We still should be able to support similar functionality. What do you mean? I don't think they should not be dual purposed. Having ownership of the "repository state" makes it clear that we have full control over how the file is changed - and we aren't preserving commenting and/or including additional metadata. Yes, I'm saying you cannot keep the session alive in general. Only certain actions would be allowable with in-flight queries, otherwise you'll end up with mismatches between the metadata associated with the query processing and the metadata in the session - and potentially run afoul of permissioning, such as the case I mentioned where the security domain changes. I'm not sure what you mean by make it the default - something will be required on the client side to denote that they expect the reconnect behavior, whether it's the failover flag or something else related to connecting to vdb that is modifiable. Sorry I was looking at CovertVDBToDDL, which is just a test utility. -- This message was sent by Atlassian JIRA (v6.4.11#64026)