The next task required of an adapter is to introspect the data source to retrieve its metadata. Set the boolean properties (Adapter Introspection Properties) according to the metadata available in the data source.

Once the introspection is completed, TDV can query the exposed metadata.

The default implementation uses JDBC DatabaseMetadata to retrieve the metadata. If that does not suffice or perform well, an alternate implementation can be provided.

For relational adapters, the standard interface for the introspector is RelationalMetaData. RelationalMetaData extends DatabaseMetadata. A custom implementation can extend AbstractRelationalMetadata to reduce the burden of implementing all of the DatabaseMetadata methods.

You can use ResultSetToMetadataConverter to translate the metadata result set into a form that the toolkit introspection API can consume.

You can use the IntrospectionFilter interface to filter out unneeded metadata items.

Note: It is important to make sure your adapter retrieves precision, scale, and length from data sources that use nonstandard names for columns in their metadata. See Determination of Precision, Scale, and Length.

Adapters use Native-to-TDV data type mappings set on the adapter Configuration tab to determine how to map from column types encountered during introspection to generic TDV data types.

When you introspect a table, you might see that the data type of a table column has unexpected attribute values, such as incorrect precision or scale or length. If this happens, the adapter might be using the wrong field in your database metadata to fetch information about those attribute values.

For example, the default implementation obtains precision from metadata this way:

Although this works for many data sources, your data source may be different. For instance, your custom data source may return precision in a field called NUMERIC_PRETDVION rather than COLUMN_SIZE. In this case you would need to retrieve it from the result set as rs.getInt(“NUMERIC_PRETDVION”).

You can solve this in one of several ways.

In Adapter configuration, under Introspection properties, find the property that specifies which field to use for precision, scale, or whatever you are trying to fix. For example, for precision the property is:

You can change the value of the property to use the appropriate field name for your data source. Also, you can use the Overrides tab in Data Source UI to override this behavior for individual data source instances.

When you change the property to specify a different field name, make sure that the metadata result set actually contains that field. If it does not, use second option and write a SQL query to fetch precision, scale, and length instead of getting it from result set metadata. For example, you may know that a system table contains precision, scale, and length in this field, but the field is not returned as part of metadata.

In your adapter extension implementation, you can extend the class AbstractRelationalMetaData and override method getColumns(), where you would place the custom logic that finds and sets precision, scale, length, or other data type details, including the data type name itself.

This is the preferred option if you want to be able to set type details in different ways depending on other conditions.

If you want to always map a specific native type to a certain fixed precision/scale/length, regardless of what comes from the database metadata, you can use Data Type Mappings in the adapter configuration.

For example, you can map native type MONEY to a TDV type DECIMAL(19, 2). However, to make TDV honor the numbers in brackets after the type in Native-to-TDV type mappings, you must go to the adapter configuration and set this Introspection property to True:

Also, you can use the Overrides tab in Data Source UI to override this behavior for individual data source instances.