Re: [teiid-designer-users] [teiid-designer-dev] Teiid Designer 7.0 Release Planning

----- "Barry Lafond" <blafond(a)redhat.com&gt; wrote: A) Designer is a Teiid design tool required for creating consumable/deployable VDB's containing indexed/queryable models. • 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. 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. 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. =============================================== ISSUE 1: Opening/Closing Model Projects in Designer Use case: I think it should be removed. I think we should do our best to keep the Teiid server uncluttered. 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. 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. I'm in favor of opening the floodgates. ISSUE 4: VDB Artifact Portability