TEIID-1971

[markaddleman]

Referring to TEIID-1971:  This looks like a huge benefit to our usecase. 

Question:  I suppose that its possible the only metadata type is DDL.  If so, is seems like the translator-name and connection-jndi-name attributes are superfluous?  My understanding is that if the DDL supplies view definitions, wouldn't those view definitions be handled by Teiid and never reach a translator nor a connection?

[rareddy]

Mark,

Referring to TEIID-1971:  This looks like a huge benefit to our usecase. 

Great! Glad to here that. Any feedback is welcome.

Question:  I suppose that its possible the only metadata type is DDL.

No, DDL is not the only type currently. Note, that the name such as "DDL" refer to a known shortcut name of a MetadataRepository implementation. The source based import in Dynamic VDB (what we had previously) is called "NATIVE". The Designer based index files use "INDEX". You can extend this interface supply your own MetadataRepository. See document here https://docs.jboss.org/author/display/TEIID/Custom+Metadata+Repository

If so, is seems like the translator-name and connection-jndi-name attributes are superfluous? 

Now based on above comment they are not. At the deployment time of the VDB, the translator is already configured, however the datasource may not have been. In that case, the MetadataRepository is supplied with a instance of "ExecutionFactory" and null connection factory. At this time the decision is left out to the MetadataRepository implementation to go forward with the metadata import/definition or simply error out because it does not see a valid connection. If the engine sees an exception, it queues back the loading of metadata only after the data source is configured. All errors are logged on the VDB, so that one see why a VDB metadata failed to load or resolve.

My understanding is that if the DDL supplies view definitions, wouldn't those view definitions be handled by Teiid and never reach a translator nor a connection?

Yes, you are correct. In case of DDL they are not used. Also, note that in case of the VIRTUAL model, they both ExecutionFactory and ConnectionFactory will be null. I did not want provide overloaded load methods, so I have designed this way.

As part of this JIRA, instead of delegation, I implemented the chain-of-responsibility pattern, such that one can insert pre or post metadata repositories to satisfy the needs.

Thanks

Ramesh..