Skip to end of metadata
Go to start of metadata

Starting with Teiid 8.0, a VDB can define models/schemas using DDL. Here is small example of how one can define a View inside the "-vdb.xml" file. See the <metadata> element under <model>.

Example to show view definition

Another complete DDL based example is at the end of this section.

Metadata Repositories
The declaration of metadata using DDL, NATIVE, or DDL-FILE is supported out of the box, however the MetadataRepository interface allows users to plug-in their own metadata facilities. For example, you can write a Hibernate based store that can feed the necessary metadata. See Custom Metadata Repository for more information.
Metadata for Source Models
The DDL based schema is not constrained to be defined only for the view models.

BNF notation for the Metadata

Grammar Reference
The full grammar for DDL can be found in the BNF for SQL Grammar.

Create FOREIGN Table

A FOREIGN table is table that is defined on PHYSICAL model that represents a real relational table in source databases like Oracle, SQLServer etc. For relational databases, Teiid has capability to automatically retrieve the database schema information upon the deployment of the VDB, if one like to auto import the existing schema. However, user can use below FOREIGN table semantics, when they would like to explicitly define tables on PHYSICAL models or represent non-relational data as relational in custom translators.

Example:Create Foreign Table(Created on PHYSICAL model)

Create View

A view is a virtual table. A view contains rows and columns,like a real table. The fields in a view are fields from one or more real tables from the source or other view models. They can also be expressions made up multiple columns, or aggregated columns. When column definitions are not defined on the view table, they will be derived from the projected columns of the view's select transformation that is defined after the AS keyword.

You can add functions, JOIN statements and WHERE clauses to a view data as if the data were coming from one single table.

TABLE/VIEW OPTIONS: (the below are well known options, any others properties defined will be considered as extension metadata)

Property Data Type or Allowed Values Description
UUID string
Unique identifier for View
MATERIALIZED 'TRUE'|'FALSE' Defines if a table is materialized
MATERIALIZED_TABLE 'table.name' If this view is being materialized to a external database, this defines the name of the table that is being materialized to
CARDINALITY int
Costing information. Number of rows in the table. Used for planning purposes
UPDATABLE 'TRUE'|'FALSE' Defines if the view is allowed to update or not
ANNOTATION string
Description of the view
DETERMINISM
  • NONDETERMINISTIC
  • COMMAND_DETERMINISTIC
  • SESSION_DETERMINISTIC
  • USER_DETERMINISTIC
  • VDB_DETERMINISTIC
  • DETERMINISTIC
Only checked on source tables
Example:Create View Table(Created on VIRTUAL model)


COLUMN OPTIONS: (the below are well known options, any others properties defined will be considered as extension metadata)

Property Data Type or Allowed Values Description
UUID string
A unique identifier for the column
NAMEINSOURCE string
If this is a column name on the FOREIGN table, this value represents name of the column in source database, if omitted the column name is used when querying for data against the source
CASE_SENSITIVE 'TRUE'|'FALSE'  
SELECTABLE 'TRUE'|'FALSE' TRUE when this column is available for selection from the user query
UPDATABLE 'TRUE'|'FALSE' Defines if the column is updatable.  Defaults to true if the view/table is updatable.
SIGNED 'TRUE'|'FALSE'  
CURRENCY 'TRUE'|'FALSE'  
FIXED_LENGTH 'TRUE'|'FALSE'  
SEARCHABLE 'SEARCHABLE'|'UNSEARCHABLE'|'LIKE_ONLY'|'ALL_EXCEPT_LIKE' column searchability, usually dictated by the data type
MIN_VALUE    
MAX_VALUE    
CHAR_OCTET_LENGTH integer  
ANNOTATION string
 
NATIVE_TYPE string
 
RADIX integer  
NULL_VALUE_COUNT long costing information. Number of NULLS in this column
DISTINCT_VALUES long costing information. Number of distinct values in this column

Columns may also be marked as NOT NULL, auto_increment, and with a DEFAULT value. Currently only string values are supported as the default value. To have the string interpreted as an expression use the extension property teiid_rel:default_handling set to expression.

CONSTRAINTS

Constraints can be defined on table/view to define indexes and relationships to other tables/views. This information is used by the Teiid optimizer to plan queries or use the indexes in materialization tables to optimize the access to the data.

CONSTRAINTS are same as one can define on RDBMS.

Example of CONSTRAINTs

INSTEAD OF TRIGGERS

A view comprising multiple base tables must use an INSTEAD OF trigger to support inserts, updates and deletes that reference data in the tables. Based on the select transformation's complexity some times INSTEAD OF TRIGGERS are automatically provided for the user when "UPDATABLE" OPTION on the view is set to "TRUE". However, using the CREATE TRIGGER mechanism user can provide/override the default behavior.

Example:Define instead of trigger on View

Create Procedure/Function

Using the below syntax, user can define a

  • Source Procedure ("CREATE FOREIGN PROCEDURE") - a stored procedure in source
  • Source Function ("CREATE FOREIGN FUNCTION") - A function that is supported by the source, where Teiid will pushdown to source instead of evaluating in Teiid engine
  • Virtual Procedure ("CREATE VIRTUAL PROCEDURE") - Similar to stored procedure, however this is defined using the Teiid's Procedure language and evaluated in the Teiid's engine.
  • Function/UDF ("CREATE VIRTUAL FUNCTION") - A user defined function, that can be defined using the Teiid procedure language or can have the implementation defined using a JAVA Class.

See the full grammar for create function/procedure in the BNF for SQL Grammar#createDDLProcedure.

Variable Argument Support
Instead of using just an IN parameter, the last non optional parameter can be declared VARIADIC to indicate that it can be repeated 0 or more times when the procedure is called positionally.

Example:Vararg procedure

FUNCTION OPTIONS:(the below are well known options, any others properties defined will be considered as extension metadata)

Property Data Type or Allowed Values Description
UUID string unique Identifier
NAMEINSOURCE If this is source function/procedure the name in the physical source, if different from the logical name given above
ANNOTATION string Description of the function/procedure
CATEGORY string Function Category
DETERMINISM
  • NONDETERMINISTIC
  • COMMAND_DETERMINISTIC
  • SESSION_DETERMINISTIC
  • USER_DETERMINISTIC
  • VDB_DETERMINISTIC
  • DETERMINISTIC
Not used on virtual procedures
NULL-ON-NULL 'TRUE'|'FALSE'
JAVA_CLASS string Java Class that defines the method in case of UDF
JAVA_METHOD string The Java method name on the above defined java class for the UDF implementation
VARARGS 'TRUE'|'FALSE' Indicates that the last argument of the function can be repeated 0 to any number of times. default false. It is more proper to use a VARIADIC parameter.
AGGREGATE 'TRUE'|'FALSE' Indicates the function is a user defined aggregate function. Properties specific to aggregates are listed below.

Note that NULL-ON-NULL, VARARGS, and all of the AGGREGATE properties are also valid relational extension metadata properties that can be used on source procedures marked as functions. See also Source Supported Functions for creating FOREIGN functions that are supported by a source.

AGGREGATE FUNCTION OPTIONS:

Property Data Type or Allowed Values Description
ANALYTIC 'TRUE'|'FALSE' indicates the aggregate function must be windowed. default false.
ALLOWS-ORDERBY 'TRUE'|'FALSE' indicates the aggregate function supports an ORDER BY clause. default false
ALLOWS-DISTINCT 'TRUE'|'FALSE' indicates the aggregate function supports the DISTINCT keyword. default false
DECOMPOSABLE 'TRUE'|'FALSE' indicates the single argument aggregate function can be decomposed as agg(agg(x) ) over subsets of data. default false
USES-DISTINCT-ROWS 'TRUE'|'FALSE' indicates the aggregate function effectively uses distinct rows rather than all rows. default false

Note that virtual functions defined using the Teiid procedure language cannot be aggregate functions.

Providing the JAR libraries
If you have defined a UDF (virtual) function without a Teiid procedure deinition, then it must be accompanied by its implementation in Java. To configure the Java library as dependency to the VDB, see Support for User-Defined Functions

PROCEDURE OPTIONS:(the below are well known options, any others properties defined will be considered as extension metadata)

Property Data Type or Allowed Values Description
UUID string Unique Identifier
NAMEINSOURCE string In the case of source
ANNOTATION string Description of the procedure
UPDATECOUNT int if this procedure updates the underlying sources, what is the update count, when update count is >1 the XA protocol for execution is enforced
Example:Define Procedure
Example:Define Virtual Function

Procedure columns may also be marked as NOT NULL, or with a DEFAULT value. Currently only string values are supported as the default value. To have the string interpreted as an expression use the extension property teiid_rel:default_handling set to expression. On a source procedure if you want the parameter to be defaultable in the source procedure and not supply a default value in Teiid, then the parameter must be nullable and use the extension property teiid_rel:default_handling set to omit.

There can only be a single RESULT parameter and it must be an out parameter. A RESULT parameter is the same as having a single non-table RETURNS type. If both are declared they are expected to match otherwise an exception is thrown. One is no more correct than the other. "RETURNS type" is shorter hand syntax especially for functions, while the parameter form is useful for additional metadata (explicit name, extension metadata, also defining a returns table, etc.)

Relational Extension OPTIONS:

Property Data Type or Allowed Values Description
native-query Parameterized String Applies to both functions and procedures. The replacement for the function syntax rather than the standard prefix form with parens. See also Translators#native
non-prepared boolean Applies to JDBC procedures using the native-query option. If true a PreparedStatement will not be used to execute the native query.
Example:Native Query
Example:Sequence Native Query
Until Teiid provides higher-level metadata support for sequences, a source function representation is the best fit to expose sequence functionality.

Options

Any option name of the form prefix:key will attempt to be resolved against the current set of namespaces. Failure to resolve will result in the option name being left as is. A resolved name will be replaced with {uri}key. See also Namespaces for Extension Metadata.

Options can also be added using the ALTER statement. See ALTER stmt.

ALTER Statement

ALTER statements currently primarily supports adding OPTIONS properties to Tables, Views and Procedures. Using a ALTER statement, you can either add, modify or remove a property.

ALTER COLUMN

ALTER OPTION

Example ALTER

ALTER statements are especially useful, when user would like to modify/enhance the metadata that has been imported from a NATIVE datasource. For example, if you have a database called "northwind", and you imported that metadata and would like to add CARDINALITY to its "customer" table, you can use ALTER statement, along with "chainable" metadata repositories feature to add this property to the desired table. The below shows an example -vdb.xml file, that illustrates the usage.

Example VDB

Data Types

The following are the supported data types in the Teiid.

Namespaces for Extension Metadata

When defining the extension metadata in the case of Custom Translators, the properties on tables/views/procedures/columns can define namespace for the properties such that they will not collide with the Teiid specific properties. The property should be prefixed with alias of the Namespace. Prefixes starting with teiid_ are reserved for use by Teiid.

Example of Namespace

Built-in Namespace Prefixes

Prefix URI Description
teiid_rel http://www.teiid.org/ext/relational/2012 Relational extensions. Uses include function and native query metadata
teiid_sf http://www.teiid.org/translator/salesforce/2012 Salesforce extensions.

Full Example showing above DDL based metadata

Full Example VDB with View Definition
Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Jul 15, 2015

    Is it possible to define the native query property for a physical table ?

    1. Jul 15, 2015

      native queries are used on source tables, see https://docs.jboss.org/author/display/TEIID/JDBC+Translator

      1. Jul 16, 2015

        I'm sorry I guesss I assumed the "FOREIGN TABLE" designation was optional.

        So am I to understand you cannot use DDL on ANYTHING physical ?

        1. Jul 16, 2015

          > I'm sorry I guesss I assumed the "FOREIGN TABLE" designation was optional.

          Foreign table means a source table.

          > So am I to understand you cannot use DDL on ANYTHING physical ?

          Teiid DDL can be used to specify both source and virtual metadata. Source metadata will have the FOREIGN keyword.

          1. Jul 16, 2015

            Ok.. then back to my original question

            Source Metadata can have a "native query" property set so is it possible to create a source table with a native query specified and do so via DDL?

            1. Jul 16, 2015

              > Source Metadata can have a "native query" property set so is it possible to create a source table with a native query specified and do so via DDL?

              Yes it can be done via DDL or extension metadata in Designer.

  2. Oct 21, 2015

    The BNF for CREATE PROCEDURE/FUNCTION is lacking in a couple areas.

    1) Need more examples representing the various combinations of statement options

    2) Not sure how users should use parameter DIRECTIONs (IN/OUT/INOUT) versus RESULT when defining a procedure that returns a single datatype'd variable?

    3) Missing info on what might happen at deployment/run-time if a there are conflicting OUT/RESULT values AND a defined RETURNS TABLE (.....) added? (i.e if both defined who wins, or will deployment fail?

    1. Oct 21, 2015

      > The BNF for CREATE PROCEDURE/FUNCTION is lacking in a couple areas.

      Do you mean the BNF or the rail road diagram above and associated text? We do have an issue with the diagrams in that they are not automatically generated, so only the BNF page is guaranteed to be accurate.

      > 1) Need more examples representing the various combinations of statement options

      Do you mean the body definition statement or the whole declaration?

      > 2) Not sure how users should use parameter DIRECTIONs (IN/OUT/INOUT) versus RESULT when defining a procedure that returns a single datatype'd variable?
      > 3) Missing info on what might happen at deployment/run-time if a there are conflicting OUT/RESULT values AND a defined RETURNS TABLE (.....) added? (i.e if both defined who wins, or will deployment fail?

      There is some overlap in the metadata here as the syntax is representing both procedures and functions.

      There can only be a single RESULT parameter and it must be an out. It is the same as having a single non-table RETURNS type. They are expected to match if both are declared. "RETURNS type" is shorter hand syntax especially for functions, while the parameter form is useful for additional metadata (explicit name, extension metadata etc.)