The following is a culmination of various discussions over the past month around what Teiid Designer 7.0 should look like or how it should be behave based on fundamental changes to the Teiid server. These changes mainly affect Admin API and migration to using the JCA compliant container technology compatible with JBoss AS. These changes have required us to re-architect Designer's connector management framework as well as a rewrite the VDB artifact creation, editing and management framework. Note that the new target "platform" for Designer includes integration with JBoss Tools plus the availability of JOPR for Teiid Server management. Please view these plans and all feeback and suggestions are welcome. Barry LaFond Teiid Designer Project Lead =============================================== Basic Functionality A) Designer is a Teiid design tool required for creating consumable/deployable VDB's containing indexed/queryable models. B) Designer is NOT a Connector/Connection Factory (CF) management tool. (JOPR/JON is) - Note that in Designer 6.0 thru 6.3 Connectors were refered to as "Connector Types" and Connection Factories were called "Connector Bindings". Designer 7.0 will be adapting the new terminology. C) Designer will provide a Teiid View (name TBD) which exposes viewable/filterable content of one or more "Teiid Servers". (Similar functionality to Release 6.3's Connectors View) - Designer allows connecting to and viewing contents of multiple Teiid Servers - Shows Connectors as children of Server - Shows CF's as children of Connectors - Shows "Source Models" (bindings) as children to CF's - Bind/Unbind features remain similar to 6.3 release - NO CF info is persisted within Designer. All of it is persisted and accessed through Teiid. - View will provide "filters" to hide Connectors if so desired. (current 6.3 feature) - View will provide "pivot" feature to show "SourceBinding-centric" view (Stretch goal) - View will support the notion of a "Default Teiid Server". Preview Data and VDB development will be tied to the current "Default Teiid Server". - Users can change their "Default Teiid Server" at any time • Not sure how Designer reacts to switching "Default Teiid Server" • Could allow migration of CF's from old Default to New Default • ... or assume user will take care of it? D) Designer will assist when needed to help user create/select CF's to either Preview Data or construct deployable VDB's. - Any Relational model created via JDBC import that contains JDBC Import info will be a candidate for auto-discovery of existing CF. - All other Relational models will required user-intervention to select an existing CF or create a compatible CF from existing Connector (i.e. type) - CF's are named with respect to the corresponding bound "Model name" - CF's created from Designer are managed from Designer and are "Model-centric". If a model is deleted from Designer, the corresponding CF is deleted from server. - Users can "Edit" a CF from Designer to change basic properties, reset password, etc... - Users cannot Create CF from Designer unless directed to via "Preview Data" or VDB editing. E) Designer will NOT perform auto-CF creation or matching during JDBC import (ala MM 5.5.3 & pre Teiid Designer 7.0) - The reasoning behind this change is a result of the role that Designer is now targeted to fill within the JBoss Tools enviroment, which is to create and test artifacts for deployment to Teiid Servers. - Instead of assuming that a users will always want to "Preview Data", for instance, we are now assuming that the may want to, so we are delaying the CF management part until actually needed. F) Designer will implement a "Hidden VDB" framework to allow Preview Data functionality. - Preview Data functionality was provided "Pre-7.0 Designer" via separate embedded Teiid code. Maintenance of this code has been expensive, so to speak, so removing that requirement has been a goal of Teiid & Teiid Designer. - The simplicity and flexibility of Teiid's ability to deploy VDB's has provided a mechanism to replace that embedded Teiid source code with a deployed "Hidden VDB" which is virtually 100% compatible with the VDB execution feature which is already a Designer requirement. - Bindings of "Source" models to CF's will be displayed in Designer's Connectors View (Name of view TBD... maybe Teiid? Execution?) - This hidden vdb will not be exposed to the user. - Hidden VDB will be created/deployed when "Preview Data" is initially requested. - Hidden VDB will be "Teiid-Server Centric" (i.e. one per server) =============================================== Related issues ISSUE 1: Opening/Closing Model Projects in Designer If users "Close" Model Projects that contain Source Model bindings to CF's on a Teiid instance, do we "filter" these CF's from the Teiid View? Would this require the concepts of "workspace" or "model project" to be included somehow in our CF properties? If a user re-opens a Model Project and there is NO info from their workspace (except maybe "model name") to re-bind their source models to CF's, how do we assist the user? Use case: 1) Create relational model "MyRelationalModel" from scratch (maybe import from text file) in "MyOwnModelProject" 2) No JDBC info embedded in model (only if created via Import from JDBC) 3) Preview relational model - results in "Select/Create CF" for relational model and Hidden VDB creation for "MyOwnModelProject" 4) User Selects/Creates CF named "MyOwnTextConnectionFactory". 4) Model now previewable and bound to "MyOwnTextConnectionFactory" CF on Teiid instance 5) User closes Model Project and Exits Designer 6) User launches Designer with previous workspace 7) User Opens "MyOwnModelProject" 8) User selects table in "MyRelationalModel" and tries to "Preview Data" Questions: - When user "closes project" will the "hidden VDB" be undeployed from server? Seems it should be removed. - If hidden VDB IS removed, then is the "MyOwnTextConnectionFactory" removed also? If so, then user has to re-create their "MyOwnTextConnectionFactory" from scratch. ISSUE 2: Switching Workspaces in Designer Eclipse provides a "Switch Workspace" feature which allows users to work on possible "different" sets of projects. If users are wiring multiple "workspaces" to the same Teiid instance, then there will be the potential for artifacts (VDB's, CF's) that may be shared between workspaces and some that won't. Are we gonna show all CF's to user? Maybe filter per workspace? If user doesn't ever re-open or delete first workspace, then CF's from that workspace would never get cleaned up. User's would have to use JON/JOPR to do that? From a usability standpoint, it seems awkward to tell Designer users to use another tool to "remove" objects created by and used solely by another tool. ISSUE 3: General CF management How do we handle CF's for VDB's that DO allow execution, but Designer DOESN'T allow preview? Note JDoyle's comment: The XML-Relational connectors have never worked with preview, you are required to do a join to get results. I s it possible to introduce the concept of a model or ConnectionFactory that does not support preview? It causes confusion for users when they try to preview and it fails. The question is still on the table whether or not Designer should just expose the basic CF management features of "Create/Edit/Delete/Import/Export". Many of the issues that have and probably will come up involve "how do we do this for the user, how do we hide this from the user and how do we fix this for the user". Allowing for general CF management could actually simplify things from a user standpoint. If we do "open the floodgates", so to speak, at least the user will "know" that no matter whether they view "Teiid" from JON or Designer, the CF's that exist are THEIR responsibility. They create, edit, delete, move etc... That actually seems the cleanest solution. ISSUE 4: VDB Artifact Portability Currently, Designer doesn't provide an "Import VDB" feature. There are potential XML Schema issues when dealing with the old "Enterprise" datatypes that prevent this. However, with the re-factoring of the Connectors framework due to Teiid JCA changes, it makes it much more attractive and almost a requirement to allow "Importing" VDB's and exploding them into the workspace. Do we want to tackle this? Create a JIRA for 7.1? Is the "Enterprise" datatypes issue solvable? Barry