This is a discussion around proposals to enhance the Teiid Metadata Importer. (no this hasn't been fully thought out, but that's where your suggestions come in).
What problem are we disucssing:
- The ability of the importer to support more than one text format
- The abiltiy of the importer to accept all the metadata that a source model can manage
What is the importer: It provides the means to import, from a file, the metadata (i.e., tables and attributes, columns and attributes, etc.) to build a source model.
What text file formats are supported: currently, only one format and only limited metadata is supported.
(1) How can the importer be changed to support more than 1 text format?
- Abstract out the text parsing implementation, so that a different implementation could be provided for different file formats or user custom format. The core importer logic would talk to an interface to ask for: getTables(), getColumns(tablenam), getIndexes(..), etc. This could be similiar to how jdbc metadata is processed. However, for a custom implementation, the user would have to provide a jar that needs to be added to the eclipse classpath and picked up by the importer. So, how does a user, in the gui, have the option to select the different/custom formats? The default ones provided by the project could be provided, but for a custom one, the user might have to change a feature file to add this to the list?
- Create a jdbc driver that can be used to import metadata by parsing the text file and returning the metadata via the DatabaseMetadata interface. This would work just like the jdbc importer, but the implementation would be specified on the URL. This would require the user to setup a Connection Profile and specify the implementation on the URL and add the custom jar (if needed).
I prefer the 1st option, but stated the 2nd in case others could make a better case for it. Or, please comment, if you have a different suggestion.
(2) Enable the importer to accept all the metadata that a source model can manager.
The currently logic only supports a limited number of metadata. The new approach is to accept all that is specified in the file that can be mapped to a metadata type in the model. And anything that doesn't map should be logged.