<html>
<head>
<base href="https://docs.jboss.org/author">
<link rel="stylesheet" href="/author/s/en/2172/19/5/_/styles/combined.css?spaceKey=TEIID&forWysiwyg=true" type="text/css">
</head>
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
<h2><a href="https://docs.jboss.org/author/display/TEIID/VDB+Versioning">VDB Versioning</a></h2>
<h4>Page <b>edited</b> by <a href="https://docs.jboss.org/author/display/~shawkins">Steven Hawkins</a>
</h4>
<br/>
<h4>Changes (2)</h4>
<div id="page-diffs">
<table class="diff" cellpadding="0" cellspacing="0">
<tr><td class="diff-snipped" >...<br></td></tr>
<tr><td class="diff-unchanged" >When a user connects to Teiid the desired VDB version can be set as a connection property \(See the [Client Developer's Guide]) in JDBC or used as part of the VDB name for OData and ODBC access. <br> <br></td></tr>
<tr><td class="diff-changed-lines" >The vdb version is set in either the vdb.xml, which is useful for dynamic vdbs, or through a naming convention of the deployment <span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;">file</span> <span class="diff-added-words"style="background-color: #dfd;">name</span> - 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. <br></td></tr>
<tr><td class="diff-unchanged" > <br>h1. Semantic Versioning <br></td></tr>
<tr><td class="diff-snipped" >...<br></td></tr>
<tr><td class="diff-unchanged" >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. <br> <br></td></tr>
<tr><td class="diff-changed-lines" >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 <span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;">file</span> <span class="diff-added-words"style="background-color: #dfd;">name</span> - vdbname.vX.X.X.vdb, e.g. marketdata.v1.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.vX or vdbname.vX.X - which is equivalent to having 0 specified for the missing version parts. Alternatively JDBC and ODBC clients may use a version restriction - - vdbname.vX. or vdbname.vX.X. - which means a VDB that must match the partial version specified. For example vdbname.v1.2. could match any 1.2 version, but would not allow 1.3+ or 1.1 and earlier. <br></td></tr>
<tr><td class="diff-unchanged" > <br>h1. Connection Type <br></td></tr>
<tr><td class="diff-snipped" >...<br></td></tr>
</table>
</div> <h4>Full Content</h4>
<div class="notificationGreySide">
<p>VDB Versioning is a feature that allows multiple versions of a VDB to be deployed at the same time with additional support to determine which version will be used. If a specific version is requested, then only that VDB may be connected to. If no version is set, then the deployed VDBs are searched for the appropriate version. This feature helps support more fluid migration scenarios. </p>
<h1><a name="VDBVersioning-VersionProperty"></a>Version Property</h1>
<p>When a user connects to Teiid the desired VDB version can be set as a connection property (See the <a href="/author/display/TEIID/Client+Developer%27s+Guide" title="Client Developer's Guide">Client Developer's Guide</a>) in JDBC or used as part of the VDB name for OData and ODBC access. </p>
<p>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.</p>
<h1><a name="VDBVersioning-SemanticVersioning"></a>Semantic Versioning</h1>
<p>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. </p>
<p>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.vX.X.X.vdb, e.g. marketdata.v1.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.vX or vdbname.vX.X - which is equivalent to having 0 specified for the missing version parts. Alternatively JDBC and ODBC clients may use a version restriction - - vdbname.vX. or vdbname.vX.X. - which means a VDB that must match the partial version specified. For example vdbname.v1.2. could match any 1.2 version, but would not allow 1.3+ or 1.1 and earlier.</p>
<h1><a name="VDBVersioning-ConnectionType"></a>Connection Type</h1>
<p>Once deployed a VDB has an updatable property called connection type, which is used to determine what connections can be made to the VDB. The connection type can be one of: </p>
<ul>
<li><b>NONE</b>- disallow new connections.</li>
</ul>
<ul>
<li><b>BY_VERSION</b>- the default setting. Allow connections only if the version is specified or if this is the earliest BY_VERSION vdb and there are no vdbs marked as ANY.</li>
</ul>
<ul>
<li><b>ANY</b>- allow connections with or without a version specified.</li>
</ul>
<p>The connection type may be changed either through the AdminConsole or the AdminAPI.</p>
<h1><a name="VDBVersioning-DeploymentScenarios"></a>Deployment Scenarios</h1>
<p>If only a select few applications are to migrate to the new VDB version, then a freshly deployed VDB would be left as BY_VERSION. This ensures that only applications that know the new version may use it.</p>
<p>If only a select few applications are to remain on the current VDB version, then their connection settings would need to be updated to reference the current VDB by its version. Then the newly deployed vdb would have its connection type set to ANY, which allows all new connections to be made against the newer version. If a rollback is needed in this scenario, then the newly deployed vdb would have its connection type set to NONE or BY_VERSION accordingly. </p>
</div>
<div id="commentsSection" class="wiki-content pageSection">
<div style="float: right;" class="grey">
<a href="https://docs.jboss.org/author/users/removespacenotification.action?spaceKey=TEIID">Stop watching space</a>
<span style="padding: 0px 5px;">|</span>
<a href="https://docs.jboss.org/author/users/editmyemailsettings.action">Change email notification preferences</a>
</div>
<a href="https://docs.jboss.org/author/display/TEIID/VDB+Versioning">View Online</a>
|
<a href="https://docs.jboss.org/author/pages/diffpagesbyversion.action?pageId=18646056&revisedVersion=4&originalVersion=3">View Changes</a>
|
<a href="https://docs.jboss.org/author/display/TEIID/VDB+Versioning?showComments=true&showCommentArea=true#addcomment">Add Comment</a>
</div>
</div>
</div>
</div>
</div>
</body>
</html>