2:31 p.m.
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