[teiid-designer-dev] Embracing Teiid 8.x and DDL

With the changes in Teiid 8.x coming on-line and the use of Dynamic VDB's in Openshift becoming more visible, it's apparent that Teiid's primary tooling (Teiid Designer) should investigate embracing these concepts and adapt accordingly. Over the past couple of weeks, I've had dialog with the Teiid team in order to understand their direction for 8.x and develop a plan take advantage of it in our Tooling/UI. At the heart of this new direction is the adaptation of a common Teiid DDL dialect for relational data definition. Options for incorporating elements of Teiid's new direction could be accomplished through drastically modifying/removing Designer's current underlying EMF framework or developing anew from a fresh perspective. Because of the size and inertia of Designer's current code-base, we deemed it beneficial to choose the latter approach. So over the next few months, the Teiid Designer community will spend some time and effort developing and prototyping a framework and initial UI dedicated to providing a compact/simplified DDL-based design tool. This framework and prototype will be referred to as "Komodo " (a type of lizard akin to Teiid, the whip-tail lizard). Komodo , based on it's maturity and applicability, could eventually replace Teiid Designer at some point in the future. Note: We are still planning on releasing Teiid Designer 8.0 and beyond in direct near-term support of Teiid 8.x releases . Below is a high-level summary detailing our intended direction with Komodo . Your comments and ideas are welcome. Major conceptual changes... 1) Simplify terminology by removing references to Models and Metamodels * Teiid is a server and framework designed to expose a VDB as a database * Tooling for Teiid should be designed to allow users to create/configure/edit schema in their VDBs * Tooling should highlight the value-added functionality of federating many different types of data sources * Tooling should highlight the ability to create/manage multiple layers of schema/VDBs to accommodate downstream data needs. * Refer to the new tooling as a " Virtual Database Design Tool " * Adapt Simple Terminology * Data Sources * Tables, columns, keys, procedures, parameters, etc.. * Virtual Schema * Unique named of containers for referencing tables, views, procedures and functions within a VDB * Virtual Metadata * Unique named schema, tables, view, procedures and functions in a VDB 2) Replace the notion of "Source Models" with "Data Sources". * Replace "Import > JDBC, etc.." with "Create Data Source" * "Schema" will return as the container or unique identifier within VDBs * Users will utilize DTP connection profile info like current tooling * Actual DDL/Metadata will be accessed through deployment of a Teiid Data source (ds.xml), deploying a dynamic VDB and retrieving the DDL through the Teiid Server * Users can also create new or edit Data Sources in the form of Tables, Procedures or Functions. * Source functions will be treated as "push-down" functions handled by the source's translator. 3) Expose Create Views or Virtual Procedures as a primary features. * Remove the need to manage multiple model types (i.e. Relational, Source, View, Web Services, XML Documents, Function and Extension) * Users create Schema to contain/organize views/tables/procedures/functions * Users define details for simpler DDL constructions: CREATE VIEW, CREATE VIRTUAL PROCEDURE, CREATE VIRTUAL FUNCTION statements. * Similar SQL definition/editing as current Teiid Designer's transformation editor * User-defined functions will be formed as "CREATE VIRTUAL FUNCTION" statements I realise that these concepts will change the dynamics of working with Teiid Designer, however, the benefits to going with "simpler is better" will hopefully: * foster improvements in usability * reduce future resources required for code maintenance * improve testability and scalability. Barry LaFond Teiid Designer Project