From 62d60b9b28acc2753e2de88efcd665b159fce27b Mon Sep 17 00:00:00 2001 From: shawkins Date: Wed, 20 Apr 2016 15:22:31 -0400 Subject: [PATCH] TEIID-3462 updating for semantic version --- admin/VDB_Versioning.adoc | 13 +++++-------- caching/External_Materialization.adoc | 4 ++-- dev/Runtime_Updates.adoc | 28 +++++++++++++-------------- 3 files changed, 21 insertions(+), 24 deletions(-) diff --git a/admin/VDB_Versioning.adoc b/admin/VDB_Versioning.adoc index d0333d3e8b..fbb43ece6e 100644 --- a/admin/VDB_Versioning.adoc +++ b/admin/VDB_Versioning.adoc @@ -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 diff --git a/caching/External_Materialization.adoc b/caching/External_Materialization.adoc index 1a3a174f11..5c556844c5 100644 --- a/caching/External_Materialization.adoc +++ b/caching/External_Materialization.adoc @@ -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), @@ -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), diff --git a/dev/Runtime_Updates.adoc b/dev/Runtime_Updates.adoc index 47cc20aee2..ce90f67a06 100644 --- a/dev/Runtime_Updates.adoc +++ b/dev/Runtime_Updates.adoc @@ -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 @@ -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 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 getProperties(String vdbName, String vdbVersion, AbstractMetadataRecord record); +void setProperty(String vdbName, String vdbVersion, AbstractMetadataRecord record, String name, String value); ----