10:41 a.m.
----- "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
5377
days inactive
5377
days old
teiid-designer-dev@lists.jboss.org
0 comments
1 participants
participants (1)
-
John Doyle