[ https://issues.jboss.org/browse/TEIID-2578?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-2578: ------------------------------------- {quote}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.{quote} You are right, no such provision in the spec, so let's keep with scenario where user needs to drop and re-create table(s), which is what I have now. {quote}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. {quote} Do you consider above drop and re-import to satisfy that need? Otherwise what you think is appropriate here? {quote}What do you mean?{quote} Never mind that comment, as long as we agree, only result of IMPORT SCHEMA|DATABASE statements are persisted then we are on same page. {quote} 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.{quote} Agree, I am just thinking what would a user might do. We should document as such. {quote}Yes, I'm saying you cannot keep the session alive in general. {quote} I mean to make the autoFailover = true by default. IMO, when security domain is changed, that should terminate all connections irrespective of this anyway. metadata concerns are valid, but I am flushing the session state? The intention is to make this seamless, if we make user login each time they issue a DDL command, usability sucks. How do other DBs handle this, I am sure we are not unique here. {quote}whether it's the failover flag or something else related to connecting to vdb that is modifiable.{quote} If we go this route, it will handle your above session termination comment. Then we can just allow to use autoFailover=true in this mode. I suspect a different connection flag may be better in case we need to separate autoFail vs edit mode. Please suggest me some name. -- This message was sent by Atlassian JIRA (v6.4.11#64026)