It has long been an issue in Designer that the development of the Teiid project has meant supporting multiple versions of Teiid when parsing, resolving and validating SQL transformations. At first, a single set of teiid client libraries was added to the Designer codebase, implying a 1-1 relationship with a version of Teiid. When Designer 8.1 came along, an attempt was made (by me) to support multiple versions of Teiid.

Broadly speaking, this has appeared to work (albeit a rather crude implementation). A user can choose a Teiid version synonymous with their Teiid instance and a default version is set in Designer. The user then has confidence that SQL validation in Designer has parity with what will happen on the . The whole idea being that the model validates in Designer and so will validate when deployed to Teiid.

The downside... (always is really!)

The development model used whereby the Teiid codebase is forked and a new submodule is generated in the Designer codebase is unsustainable. There are already 3 submodules (7.7, 8.3, 8.4)! Strictly speaking, 8.3 is unnecessary but at the time there was always some question over compatibility between Teiid 8.3 and 8.4 so for historical reasons it lives on.

With the advent of the next generation of Designer tool (codenamed Komodo), we wanna move totally away from submodules BUT we need a teiid client runtime that can still support multiple versions of Teiid. This is tricky since some objects in Teiid are backward-compatible, eg. the resolver, but other objects are not, eg. the parser, admin client (between 7 and 8). We need to support all of them.

So, what's the plan??

Jboss tools has the same issues in supporting multiple versions. One of that project's solutions is to provide generic interfaces and where objects have to differ, create internal version-specific implementations but present them under the one interface. Thus, one teiid-client-runtime plugin that is wholly backward-compatible between Teiid versions (back to 7.7.x) and where necessary implements v7, v8 ... objects that are used depending on a required Teiid version.

Simple really!

Indeed, but getting the framework up and running is a challenge and just getting 2 versions of the parser up to parity has taken quite an effort. Current work is maintained on my teiid-runtime branch (careful! I force push this branch with any work-in-progress so let me know if you pull from it).

Back to code...

PGR