Re: [teiid-designer-users] [teiid-designer-dev] Teiid Designer 7.0 Release Planning
by John Doyle
----- "Barry Lafond" <blafond(a)redhat.com> wrote:
>
> 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? >
If we go to the length of migrating CF's, then I think we should make it configurable. For instance, when the user changes the default, we pop up a dialog asking if they want to migrate the CFs to the new default "in order to enable execution of the current model projects on the new default". We could limit it to open model projects, and add a checkbox on the dialog to "remember my choice".
What about Connectors? If we switch defaults and the new default is lacking a connector? I don't think Designer should migrate Connectors, but we should fail gracefully with an appropriate message and migrate projects that won't work in the new default.
> 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.
>
So when does a user create the ConnectionFactory? During VDB creation (OK get that), or after they hit the "Running Man" button? Historically that button was deactivated until the model was bound, so is the action now that the button is always active and when the user clicks it for the first time for a model they are prompted to create the CF?
I just want to add in here the wrinkel that XML-Relational models should never be previewed, so it would be nice if I could deactivate preview all together for certain types of models.
> 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)
>
>
Will this be a single hidden VDB for a designer connection to Teiid, or a hidden VDB per model project? I ask because I'm concerned about name collisions that might requires us to use fully qualified SQL in the preview queries.
===============================================
> 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.
>
I think it should be removed. I think we should do our best to keep the Teiid server uncluttered.
> - If hidden VDB IS removed, then is the "MyOwnTextConnectionFactory" removed also? If so, then user has to re-create their "MyOwnTextConnectionFactory" from scratch.
>
Designer will have the capability to export the CF from Teiid, correct? We could document that for cases like this (text, xml, soap, salesforce, google spreadsheets) the user should export the CF into their model project. They could then import the CF back into Teiid when opening the model again.
> 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.
Are you asking about concurrent connections from multiple workspaces here? I've read everything above with the understanding that what is deployed into Teiid from designer in terms of preview and VDB execution ( as opposed to actually Exporting a VDB into Teiid) was cleaned up when Designer was shut down. Perhaps a bad assumption on my part, but it is the way I think Designer should function. I think we should aggresively undeploy from Teiid.
Operating from that assumption, if I switch from workspace X to workspace Y, everything from X would get undeployed as Designer switched. If X wanted to share a CF or VDB, then the CF would have to be exported, shared with Y, and imported by Y. A VDB would have to be actually deployed to be shared.
This assumption however doesn't free us from my use of two workspaces at the same time, or a shared use of a Teiid server in any form. Even if we did filter per workspace, we could end up with clashes. What if you created a CF called MyCF, and I tried to do the same. Because we've filtered I can't see yours, but I fail to create mine.
>
> 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. Is 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.
I'm in favor of opening the floodgates.
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
>
> _______________________________________________ teiid-designer-dev mailing list teiid-designer-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
14 years
- 1
- 0
Teiid Designer 7.0 Release Planning
by Barry Lafond
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
14 years
- 1
- 0
- ← Newer
- 1
- Older →