Overview of Extension Adapter Configuration
When you assemble a deployable package, you have a choice of what to do about the configuration. If several adapters are in the package, you can make different choices for each adapter.
Completeness of Original Configuration
What TDV does with a newly deployed adapter depends on the state of its original configuration:
• If an adapter configuration file is not provided for an adapter, then during package deployment the adapter is assigned a default configuration that contains the most common settings for relational data sources.
Because TDV does not know anything about the new data source, some assigned property values may be incorrect for this new data source. Therefore, after deployment you need to open the adapter configuration in Studio and change property values systematically so they accurately describe the data source’s characteristics. Also, it is crucial that you provide information about native data types.
• If an adapter configuration file is provided for an adapter, but the file does not contain the minimum set of properties and property values that TDV requires, the adapter configuration file is first validated. Upon successful validation, the adapter configuration file is merged with the collection of all required and optional properties.
After deployment, you need to open the adapter configuration file in Studio to make sure all the properties have appropriate values for the data source at hand. Make sure the adapter configuration file specifies information about native data types.
• If an adapter configuration file contains the minimum required set of properties and property values, then upon successful validation the adapter is fully enabled and can create data source instances.
If the adapter configuration file does not define at least ten functions, the adapter is merged with the full list of all functions known to TDV; otherwise, to save developer time, the merge is not done.
It is still advisable to go through the adapter configuration in Studio and make sure the merged result is appropriate to the intended data source. Make sure the adapter configuration file specifies information about native data types.
Configuration Planning
When you are setting up the adapter configuration in Studio, these are the main questions to consider:
• Which properties do you want to expose in the data source UI, and which do you not want to expose? Set visibility flags accordingly.
• Which properties should be required? Set visibility flags accordingly.
• Which properties do you want to allow data sources to override? Set visibility flags accordingly.
• What are all the native types and how should they map to Composite data types? How should Composite data types map to the native data types? Set data type mappings in both directions, defining additional data types as needed.
• Which properties are relevant? Set default values for them and delete the others.
• What is unsupported in SQL clauses? Specify those data types.
• Which operators and functions are supported? Set native expressions and arguments appropriately and delete the others.
• Are additional operators or functions needed? If so, define custom operators and functions.
Validation of Configuration When Adapter Configuration Is Saved
When you save changes made on either the Configuration tab or the Text tab, a validity check is made:
• If the adapter configuration file (a YAML document) is malformed or produces errors, it is not saved.
• If you edited the adapter configuration file directly (on the Text tab), the file could be invalid because of:
— Schema errors in the structure of the document (for example, the wrong number of space characters before terms)
— Use of characters that are not allowed (for example, tab characters; use spaces)
— Misspellings, or uppercase where lowercase is required
— Unexpected elements
• If validation produces only warnings, the deployment succeeds, and the validation warning messages are written to the server log.
As part of a successful validity check, some changes may be made automatically. For example:
• If Required for data source is set to true but Display in UI is set to false, the validity checker changes Display in UI to true so that the person configuring the data source can set the value.
• If a data type prefix of “cis.” or “native.” is used for a valid data type but the prefix is not needed, it is removed before the data type is saved.