Using Ramesh's list of which methods to keep/throw away for the 6.3
release, I only found 1 change that I thought was needed. That was
the "getTransactions" was in the throw away list. This is because,
if the "terminateTransaction" method is to remain, doesn't it need a
corresponding method to return the transactions in order to know/find
which transaction to terminate?
Other than that, nothing else.
Also, I started commenting on why the throwaway list of methods will
be gone to help explain/insight to the changes that are occurring.
// methods to keep
getVDBs (from a vdb, the models can be obtained, and from a model,
the connector(s) can be found)
getRequests (also enable monitor long running queries)
// Can these me removed?
// Can be removed
1. the connector type information will be defined in the ra.xml for
its respective connector rar file.
2. JCA connectors will now be managed by the app server
3. Extension modules will now be deployed as part of the connector
4. There is no longer be a configuration file, as in the past.
5. Process management is no longer part of Teiid
6. Start / Stop /Restart of Teiid engine is managed by the app
servers' management of JCA
7. Change in logging infrastrucure
Principal Software Eng.
Red Hat, Inc.
I have uploaded the changes to take care of the functionality.
- Connector can be exported as RAR to any directory. Application remembers
the exported directory
- Projects with errors are not exported; users are notified using an error
- Cdk nature has been added which will give a custom icon to any Cdk
- Temporary files are deleted.
- Runtime errors had been notified using dialog box,
Let me know if you would like to me change something or you come across any
I checked in the Cdk plugins for review. It's available from :
1. There are currently 3 plugin:
- org.teiid.cdk.connector.v610 : Wrapper plugin for *teiid-6.1.0-cdk-dist*
- org.teiid.cdk.connector.v620 : Wrapper plugin for *teiid-6.2.0-M3-cdk-dist
- org.teiid.cdk.core : Main plugin responsible for code generation and
2. The wizard can be invoked from these perspective right-clicking on New in
3. The wizard is self-explanatory for creating a CDK Projects
4. The sources can be imported, built and executed in eclipse workspace. The
plugins had been tested with Galileo 3.5, 3.6
5. To build and deploy, the cdk wrapper plugins can be built and deployed as
individual jars, however the cdk-core plugin must be built and deployed
6. In order to test new cdk-distributions, similar wrapper plugins to be
built and extension point to be used to publish jars. To understand the
wirings, plugin.xmls from *teiid-6.1.0-cdk-dist *and *
teiid-6.2.0-M3-cdk-dist* to be compared. All the jar paths are relative to
the sdk directory location specified through the extension point.
7. Project names are converted to lowercase and prepended with the word
"connector-"; so the project name, LoopBack, will be converted to
"connector-loopback". Any new project with the same name loopback (case
insensitive) cannot be furthur created.
8. Errors are currently logged using eclipse infrastructure. Most of the
common project creation errors are handled.
9. Presently the following features are not available:
- Maven container integration : The project currently cannot be built as a
maven project; however the maven directory structure exist with necessary
project setting for proper compilation in eclipse
- CDK Preference
Just a quick change notice for anyone looking to move to the upcoming 7.0 M1.
TEIID-145 changes our old default handling of treating double quoted strings as string literals to instead use ANSI rules that always treat double quoted strings as identifiers. See the issue comments if you want to continue using the old non-standard behavior.
TEIID-870 changes our JDBC metadata to report the vdb name as the catalog and the model name as the schema. Any direct usage of Teiid's DatabaseMetadata will need to account for this - e.g. instead of using the vdb name as a schema pattern, it should be passed as the catalog. And any searches using a table name should not include the model name as part of the table name.
TEIID-869 system tables have been changed to better reflect our metadata internals. Most notably, the properties tables have all been collapsed into a single table. Something to consider is that to facilitate legacy vdbs we may also want to change the name of the schema so that it doesn't conflict if we also add in the old System schema.
Let me know if there are any questions,
After more thought, we will delay MS until there are more comprehensive changes made to our metadata. This will include re-updating the system tables to remove unnecessary derived columns, to change our model/group/element terminology to schema/table/column, and to work TEIID-870 (JDBC metadata changes). This should take at least 1 week.
Keep in mind that one of the next milestones will then include the container related changes. This will dramatically change how Teiid is deployed. You should follow JCA branch if you want an early preview.
Given the scope of changes for 6.3 (metadata changes that are already in, container and caching changes that are pending) there is case to be made for promoting 6.3 to be the 7.0 release. Most of the existing 7.0/7.x issues would then become part of an 8.x release. The 7.x release line (7.1, etc.) would further refine the new deployment model and continue to make targeted, rather than sweeping, query changes. If we make the change to 7.0, I would also propose lengthening the release cycle out to Jan 8th to allow for more changes and testing that would be expected with a major release number.
Regardless we will look at getting a milestone out this week to promote usage of the changes made to date.
Does anyone feel strongly one way or another?
I am looking for *metamatrix-cdk.jar*; where can I find it ? The loopback
connector classes gives compilation error for *