[JBoss JIRA] Resolved: (TEIIDDES-394) Association between a model and a connector binding for use by the Preview functionality should be stored within the model
by Barry LaFond (JIRA)
[ https://jira.jboss.org/browse/TEIIDDES-394?page=com.atlassian.jira.plugin... ]
Barry LaFond resolved TEIIDDES-394.
-----------------------------------
Resolution: Done
This has been done via other JIRA's required to wire-up COnnection Profiles and models. Basically we're storing CP into in model (except pwd) and using it to discover translator types and to help create data sources in Teiid during Preview Data action.
> Association between a model and a connector binding for use by the Preview functionality should be stored within the model
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: TEIIDDES-394
> URL: https://jira.jboss.org/browse/TEIIDDES-394
> Project: Teiid Designer
> Issue Type: Feature Request
> Components: Import/Export
> Environment: Designer 5.5.3
> Reporter: Greg Haber
> Assignee: Barry LaFond
> Priority: Minor
> Fix For: No Future
>
>
> The proposal here is that a weak association between a model and the connector binding it is associated with for design time preview functionality should be stored in the model file itself, and used to re-establish the association for preview functionality when that model is brought into Designer (such as when an import of a Model Project Set is performed).
> The association would be stored in the model with a minimum of information (just the binding name), and the proposed logic is that if there is already an existing binding in Designer with name matching that in the model file, the association for Preview will be automatically established with that binding.
> I have attached an e-mail thread between me and rreddy on this topic.
> One wrinkle here (not explicitly discussed in the e-mail thread) is if the referenced binding in the model does not previously exist in the Designer workspace, but _is_ defined by a VDB contained in the same model project set, and feature JBEDSP-287 is implemented (so that such VDB binding definitions do get brought in during import). It would be good if the association for Preview functionality between model and binding could also be re-established in this case. This would presumably require that the import of a model project set first import any VDBs before it imported design time models.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 6 months
[JBoss JIRA] Updated: (TEIIDDES-219) SFDC importer plugin has copies of lots of 3rd party jars that maybe should be in sep plugins
by Barry LaFond (JIRA)
[ https://jira.jboss.org/browse/TEIIDDES-219?page=com.atlassian.jira.plugin... ]
Barry LaFond updated TEIIDDES-219:
----------------------------------
Assignee: John Doyle
Fix Version/s: 7.2
(was: 7.1)
> SFDC importer plugin has copies of lots of 3rd party jars that maybe should be in sep plugins
> ---------------------------------------------------------------------------------------------
>
> Key: TEIIDDES-219
> URL: https://jira.jboss.org/browse/TEIIDDES-219
> Project: Teiid Designer
> Issue Type: Quality Risk
> Components: Documentation, Import/Export
> Affects Versions: 6.0.0
> Environment: Designer 5.5.3 MS1 build
> Reporter: Greg Haber
> Assignee: John Doyle
> Priority: Minor
> Fix For: 7.2
>
>
> I noticed that as of MS1, the SFDC importer plugin contains a lot of copies of third party jars, most Apache Axis/Apache Commons stuff. In many cases, these same jars are also in the com.metamatrix.modeler.dqp_5.5.3 plugin since they are also needed by the SFDC connector. I also noticed that some of our other Designer plugins that use external jars put those jars in their own plugins, and import the plugin, rather than putting them in the same plugin as our own code.
> We should consider pulling these jars out of the SFDC importer plugin and putting them in their own plugins (which the SFDC importer plugin can then import), or simply importing them in the SFDC importer plugin from the DQP plugin.
> The same problem exists to a much lesser degree in the WSDL importer (just the commons-codec-1.2.jar is duplicated in that one).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 6 months
[JBoss JIRA] Updated: (TEIIDDES-239) CLONE -Fully-qualified names should not be required when referencing virtual procedures that have unique unqualified names
by Barry LaFond (JIRA)
[ https://jira.jboss.org/browse/TEIIDDES-239?page=com.atlassian.jira.plugin... ]
Barry LaFond updated TEIIDDES-239:
----------------------------------
Fix Version/s: 8.0
(was: 7.1)
> CLONE -Fully-qualified names should not be required when referencing virtual procedures that have unique unqualified names
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: TEIIDDES-239
> URL: https://jira.jboss.org/browse/TEIIDDES-239
> Project: Teiid Designer
> Issue Type: Feature Request
> Affects Versions: 6.1.0, 6.2.0
> Reporter: Michael Walker
> Priority: Minor
> Fix For: 8.0
>
>
> This problem occurs in our transformation editor, and also occurs with real-time queries (e.g. from QueryBuilder/SQLExplorer, or any client).
> If you reference a non-qualified table name, e.g. "myTable", in a query, we'll attempt to resolve it if it is a unique name.
> Strangely, we don't do the same thing for virtual procedures, even if they are unique. Instead, you must use the fully-qualified name. There should be no disparity. This is a usability defect.
> This also happens to greatly extend the size of virtual procedure code, making it harder to read and debug.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 6 months