]
Barry LaFond updated TEIIDDES-1250:
-----------------------------------
Fix Version/s: 8.3
Need to improve the concept of how we're using and presenting the
standard File and Web Service procedures
----------------------------------------------------------------------------------------------------------
Key: TEIIDDES-1250
URL:
https://issues.jboss.org/browse/TEIIDDES-1250
Project: Teiid Designer
Issue Type: Enhancement
Components: Modeling
Reporter: Barry LaFond
Priority: Critical
Fix For: 8.3
Attachments: TEIIDDES-1250.txt
As we're developing more and more importers and model generators that utilize or
require a source model containing getText(), getTextFiles(), invoke() or invokeHTTP(), it
seems that we're spending a lot of time:
1) Re-coding the logic to generate them to utilize the "Source" or connection
profile stored in them
2) Explaining to the user that this is "Required" and how/why it's
happening.
The ONLY reason user-intervention is required is because currently, a Source model is
needed as the carrier of the specific FILE or WSDL URL information. (Used to create
"Data Source")
If this File/WSDL URL info was NOT included in these source models, then we could create
a Built-in FileFunctions.xmi Source model that's delivered with the product and
included in a VDB ANY time it's required.
To make this happen, we'd need another mechanism to persist the connection
information and that might be the "View Model" that contains the SQL that
contains the actual "File" or "URL" definition. This sort of makes
sense.
I know our current "Preview Data" and "Create Data Source" framework
only works with Source models, but if we could change this behavior we would save a LOT of
pain and anguish for the user AND us developers in the future.
Currently this would simplify 3 different import wizards, remove a couple of Options in
the "New > Teiid Metadata Model > Relational" wizard use case and remove a
step or two from EACH cheat sheet or section in the documentation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: