[teiid-dev] Connector supplied metadata
https://jira.jboss.org/jira/browse/TEIID-684 covers allowing connectors to supply
metadata. An initial check-in of this feature was added last night. For those that are
interested have a look at TestVDBLessExecution in the test-integration module.
Through just a ConfigurationInfo.def file:
<VDB>
<VDBInfo>
<Property Name="Name" Value="VDBLess" />
<Property Name="Version" Value="4" />
<Property Name="UseConnectorMetadata" Value="true" />
</VDBInfo>
<Model>
<Property Name="Name" Value="SummitData" />
<ConnectorBindings>
<Connector Name="Text Connector" />
</ConnectorBindings>
</Model>
<ConnectorBindings>
<Connector Name="Text Connector" ComponentType="Text File
Connector">
<Properties>
<Property Name="Immutable">true</Property>
<Property
Name="DescriptorFile">src/test/resources/vdbless/TextDescriptor.txt</Property>
</Properties>
</Connector>
</ConnectorBindings>
</VDB>
The text connector supplies the metadata for the SummitData model (through the
TextDescriptor file). I'll have the wiring added for the JDBC connector shortly along
with additional metadata features, such as keys and procedures.
Note that the changes have heavily refactored the metadata module. The intention is for
6.2 Designer to specifically fork the the 6.1 version of the metadata code to provide
their own implementation of the QueryMetadataInterface with their legacy usage of
MetadataRecords. This does not require any api level changes on their part or changes to
the current preview integration mechanism. There are currently no plans to incorporate
this work into Designer as this is currently envisioned for ease of use of stand-alone
Teiid.
An issue that is open for discussion is that the connector api now exposes the
MetadataRecord objects as well as it the MetadataObject interfaces (Group, Element, etc).
A case could be made for expanding the MetadataObject interfaces to include getters and
setters for all relevant fields on MetadataRecords (there are currently many fields that
the user doesn't need to modify that are only used by index logic or are handled by
the MetadataFactory). We still however would need to have separate implementations of the
interfaces since the Designer preview feature would still provide metadata through its QMI
in the from of legacy MetadataRecords. If we do expand the interfaces in this way, we
would also probably want to add logic to ensure that no modifications can be performed
when the records are supplied as RuntimeMetadata.
One warning that should be added is that since the metadata is non-persistent direct usage
of uuid values in system tables should be discouraged.
Steve