Skip to content

Commit

Permalink
TEIID-3462 updating for semantic version
Browse files Browse the repository at this point in the history
  • Loading branch information
shawkins committed Apr 20, 2016
1 parent 70a361c commit 62d60b9
Show file tree
Hide file tree
Showing 3 changed files with 21 additions and 24 deletions.
13 changes: 5 additions & 8 deletions admin/VDB_Versioning.adoc
Expand Up @@ -7,16 +7,13 @@ VDB Versioning is a feature that allows multiple versions of a VDB to be deploye

When a user connects to Teiid the desired VDB version can be set as a connection property (See the link:../client-dev/Client_Developers_Guide.adoc[Client Developer’s Guide]) in JDBC or used as part of the VDB name for OData and ODBC access.

The vdb version is set in either the vdb.xml, which is useful for dynamic vdbs, or through a naming convention of the deployment name - vdbname.version.vdb, e.g. marketdata.2.vdb. The deployer is responsible for choosing an appropriate version number. If there is already a VDB name/version that matches the current deployment, then connections to the previous VDB will be terminated and its cache entries will be flushed. Any new connections will then be made to the new VDB.
The vdb version is set in either the vdb.xml, which is useful for an xml file deployment, or through a naming convention of the deployment name - vdbname.version.vdb, e.g. marketdata.2.vdb. The deployer is responsible for choosing an appropriate version number. If there is already a VDB name/version that matches the current deployment, then connections to the previous VDB will be terminated and its cache entries will be flushed. Any new connections will then be made to the new VDB.

== Semantic Versioning
A simple integer version actually treated as the semantic version X.0.0. If desired a full semantic version can be used instead. A semantic version is up to three integers separated by periods.

If a simple integer version is not sufficient, then semantic versioning can be used instead. Semantic version are used instead of the version property and appear as part of the VDB name.

Setting the version can either be done in the vdb.xml, which is useful for dynamic vdbs, or through a naming convention of the deployment name - vdbname.X.X.X.vdb, e.g. marketdata.1.2.1.vdb.
The deployer is responsible for choosing an appropriate version. If there is already a VDB name/version that matches the current deployment, then connections to the previous VDB will be terminated and its cache entries will be flushed.
Any new connections will then be made to the new VDB. JDBC and ODBC clients may use a shorthand version - vdbname.X or vdbname.X.X - which is equivalent to having 0 specified for the missing version parts.
Alternatively JDBC and ODBC clients may use a version restriction - -vdbname.X. or vdbname.X.X. - note the trailing '.' which means a VDB that must match the partial version specified. For example vdbname.1.2. could match any 1.2.X version, but would not allow 1.3+ or 1.1 and earlier.
Trailing version components that are missing are treated as zeros - version 1 is the same as 1.0.0 and version 1.1 is the same as 1.1.0.

JDBC and ODBC clients may use a version restriction - -vdbname.X. or vdbname.X.X. - note the trailing '.' which means a VDB that must match the partial version specified. For example vdbname.1.2. could match any 1.2.X version, but would not allow 1.3+ or 1.1 and earlier.

== Connection Type

Expand Down
4 changes: 2 additions & 2 deletions caching/External_Materialization.adoc
Expand Up @@ -35,7 +35,7 @@ NOTE: The Designer tooling for this feature is lacking at this moment but this w
CREATE TABLE status
(
VDBName varchar(50) not null,
VDBVersion integer not null,
VDBVersion varchar(50) not null,
SchemaName varchar(50) not null,
Name varchar(256) not null,
TargetSchemaName varchar(50),
Expand Down Expand Up @@ -186,7 +186,7 @@ MATERIALIZED_TABLE is necessary, it can be any name, but it’s structure should
CREATE TABLE status
(
  VDBName varchar(50) not null,
  VDBVersion integer not null,
  VDBVersion varchar(50) not null,
  SchemaName varchar(50) not null,
  Name varchar(256) not null,
  TargetSchemaName varchar(50),
Expand Down
28 changes: 14 additions & 14 deletions dev/Runtime_Updates.adoc
Expand Up @@ -42,10 +42,10 @@ See the Reference for the system procedures `SYSADMIN.setColumnStats` and `SYSAD

[source,java]
----
TableStats getTableStats(String vdbName, int vdbVersion, Table table);
void setTableStats(String vdbName, int vdbVersion, Table table, TableStats tableStats);
ColumnStats getColumnStats(String vdbName, int vdbVersion, Column column);
void setColumnStats(String vdbName, int vdbVersion, Column column, ColumnStats columnStats);
TableStats getTableStats(String vdbName, String vdbVersion, Table table);
void setTableStats(String vdbName, String vdbVersion, Table table, TableStats tableStats);
ColumnStats getColumnStats(String vdbName, String vdbVersion, Column column);
void setColumnStats(String vdbName, String vdbVersion, Column column, ColumnStats columnStats);
----

=== Schema Updates
Expand All @@ -54,15 +54,15 @@ See the Reference for supported DDL statements. To make schema updates persisten

[source,java]
----
String getViewDefinition(String vdbName, int vdbVersion, Table table);
void setViewDefinition(String vdbName, int vdbVersion, Table table, String viewDefinition);
String getInsteadOfTriggerDefinition(String vdbName, int vdbVersion, Table table, Table.TriggerEvent triggerOperation);
void setInsteadOfTriggerDefinition(String vdbName, int vdbVersion, Table table, Table.TriggerEvent triggerOperation, String triggerDefinition);
boolean isInsteadOfTriggerEnabled(String vdbName, int vdbVersion, Table table, Table.TriggerEvent triggerOperation);
void setInsteadOfTriggerEnabled(String vdbName, int vdbVersion, Table table, Table.TriggerEvent triggerOperation, boolean enabled);
String getProcedureDefinition(String vdbName, int vdbVersion, Procedure procedure);
void setProcedureDefinition(String vdbName, int vdbVersion, Procedure procedure, String procedureDefinition);
LinkedHashMap<String, String> getProperties(String vdbName, int vdbVersion, AbstractMetadataRecord record);
void setProperty(String vdbName, int vdbVersion, AbstractMetadataRecord record, String name, String value);
String getViewDefinition(String vdbName, String vdbVersion, Table table);
void setViewDefinition(String vdbName, String vdbVersion, Table table, String viewDefinition);
String getInsteadOfTriggerDefinition(String vdbName, String vdbVersion, Table table, Table.TriggerEvent triggerOperation);
void setInsteadOfTriggerDefinition(String vdbName, String vdbVersion, Table table, Table.TriggerEvent triggerOperation, String triggerDefinition);
boolean isInsteadOfTriggerEnabled(String vdbName, String vdbVersion, Table table, Table.TriggerEvent triggerOperation);
void setInsteadOfTriggerEnabled(String vdbName, String vdbVersion, Table table, Table.TriggerEvent triggerOperation, boolean enabled);
String getProcedureDefinition(String vdbName, String vdbVersion, Procedure procedure);
void setProcedureDefinition(String vdbName, String vdbVersion, Procedure procedure, String procedureDefinition);
LinkedHashMap<String, String> getProperties(String vdbName, String vdbVersion, AbstractMetadataRecord record);
void setProperty(String vdbName, String vdbVersion, AbstractMetadataRecord record, String name, String value);
----

0 comments on commit 62d60b9

Please sign in to comment.