[teiid-issues] [JBoss JIRA] (TEIID-2578) add/remove schema elements

[Steven Hawkins (JIRA)]

    [ https://issues.jboss.org/browse/TEIID-2578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291399#comment-13291399 ] 

Steven Hawkins commented on TEIID-2578:
---------------------------------------

> What about procedures? I could not think of way to wedge those into the SQL/MED's IMPORT statement.

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.

> My thinking is if the refresh of metadata is needed then the IMPORT command needs to be executed again, if the specific tables are defined in the IMPORT and target schema already has the tables then a update of the metadata is performed on on those tables, any new ones will be added. 

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.

> Some of the metadata loading based on the knowledge that persisted VDB always has all the metadata. This way the IMPORT failures or data source non-availability issues are handled when user is actually performing the task, not at other times like start of the server.

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.

> I consider the usage of NativeMetadataRepository equal to some one running the DDL ad-hoc.

What do you mean?

> Also, I am not expecting anyone to directly edit these files, but if at all these make into any SCM, then that is a possible pattern users might do.

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.

> The way I have it right now is, user will only be able to edit VDB that is created through "CREATE DATABASE" construct, where I have the metadata of VDB available in the DatabaseStore object. Also when one issues an "Alter" I do re-validate to make sure that is allowed. As per session, I wired such that I flush out the state of the session, but keep the connection during the VDB modifications. I thought that covers issue, and gives that seamless continuity. Do you see issues with that?

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.

> We don't recommend anyone editing in production anyway. When VDB is dropped or re-created using "DROP DATABASE/CREATE DATABASE" then sessions behave like they do currently. IMO, AutoFailover=true is fine but, we need to make that default for editing VDBs, that is users expect anyway when they replace the VDBs with same name and version.

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.

> The convert utility is the current "get-schema" method on the Admin API. It is always associated with the running server. I am basing the convert on running VDB metadata, rather than the deployment time resolution of metadata of VDB. Inline with IMPORT comment above.

Sorry I was looking at CovertVDBToDDL, which is just a test utility.

> Yes, this is an issue. IMO we can piggy back on the ALTER grant for this, once we have the connection working over the JDBC I can take a look at this.






> add/remove schema elements
> --------------------------
>
>                 Key: TEIID-2578
>                 URL: https://issues.jboss.org/browse/TEIID-2578
>             Project: Teiid
>          Issue Type: Feature Request
>          Components: Query Engine
>            Reporter: Ramesh Reddy
>            Assignee: Ramesh Reddy
>             Fix For: 9.1
>
>
> Schemas are currently static after load.  Modifications can only happen with restarts or new versions.  We should allow add/drop at runtime.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)