[
https://jira.jboss.org/browse/TEIID-1187?page=com.atlassian.jira.plugin.s...
]
Steve Hawkins commented on TEIID-1187:
--------------------------------------
Changed vdb translatorrepository and connectormanager repository scoping in the code, so
that they are associated directly with the vdb. This ensures that on undeploy (whether
it's overwritten or removal) current connections are intact.
There is no good way to achieve #2 with removing the vdb version field - it would require
us to introduce an indirection mechanism that doesn't yet exist.
So for now we'll stick with version, which also limits public api changes. A possible
scheme could be:
Setting the version can either be done in the vdb.xml, which is likely for dynamic vdbs,
or through a naming convention of the deployment file - vdbname.version.vdb. JOPR will
need to be updated so that vdb deployments can be based upon url and so that the deployed
filename can be specified (this is already possible through the admin api). The deployer
is responsible for choosing an appropriate version #.
We'll also break out the vdb status field into a non-updatable status and an updatable
connection type. The connection type can be one of:
NONE - disallow new connections TODO: this could even mean purge existing connections
BY_VERSION - 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
ANY - allow connections with or without a version specified.
When a vdb is deployed it will by default have the BY_VERSION connection type. Deployment
screens/api could optionally be updated to set the connection type.
If only a select few applications are to migrate, then a freshly deployed vdb would be
left as BY_VERSION
If only a select few applications are to remain on the current, then they would need to be
updated to reference it by version, then the newly deployed vdb would be set to ANY.
If a rollback is needed, then the newly deployed vdb would be set to NONE or BY_VERSION.
Refine vdb version logic
------------------------
Key: TEIID-1187
URL:
https://jira.jboss.org/browse/TEIID-1187
Project: Teiid
Issue Type: Quality Risk
Components: Server
Affects Versions: 7.1
Reporter: Steve Hawkins
Assignee: Steve Hawkins
Fix For: 7.1
We no longer have a built in configuration repository and we rely on container scans to
do deploys, so we have lost the ability to internally control the notion of a deployed vdb
version.
We should strive for the following:
1. Overwrite of a deployed vdb should not invalidate or otherwise corrupt current
connections.
2. Switching to a different vdb as the new default for a particular name should not
require two deployments of the same vdb.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira