[JBoss JIRA] Created: (TEIIDDES-216) Designer removes parentheses around criteria in ansi join when using compound ON
by Marc Shirley (JIRA)
Designer removes parentheses around criteria in ansi join when using compound ON
--------------------------------------------------------------------------------
Key: TEIIDDES-216
URL: https://jira.jboss.org/jira/browse/TEIIDDES-216
Project: Teiid Designer
Issue Type: Bug
Affects Versions: 6.1.0
Reporter: Marc Shirley
In Designer, when validating a transformation that has compound criteria in an ansi join statement's ON, the parentheses are removed and the order of operations is modified as a result. This does not appear to occur when using the same parentheses structure in WHERE criteria.
Before validation:
SELECT * FROM bqt.SMALLA AS a INNER JOIN bqt.SMALLB AS b ON (a.INTKEY = b.INTKEY) AND (a.INTNUM IS NULL OR a.INTNUM = 11)
After validation:
SELECT * FROM bqt.SMALLA AS a INNER JOIN bqt.SMALLB AS b ON a.INTKEY = b.INTKEY AND (a.INTNUM IS NULL) OR (a.INTNUM = 11)
After validating a second time:
SELECT * FROM bqt.SMALLA AS a INNER JOIN bqt.SMALLB AS b ON ((a.INTKEY = b.INTKEY) AND (a.INTNUM IS NULL)) OR (a.INTNUM = 11)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] Created: (TEIIDDES-122) Add WSDL 2.0 Support to Designer for Data Services
by Ted Jones (JIRA)
Add WSDL 2.0 Support to Designer for Data Services
--------------------------------------------------
Key: TEIIDDES-122
URL: https://jira.jboss.org/jira/browse/TEIIDDES-122
Project: Teiid Designer
Issue Type: Feature Request
Affects Versions: 6.0.0
Reporter: Ted Jones
Fix For: 6.0.0
In order to support REST (see TEIID-417), we need to allow for the generation of WSDL 2.0 specific WSDL. We still need to allow for the generation of WSDL 1.1 since WSDL 2.0 is not widely supported by many tools.
There should be an option in the Designer to specify which version of the WSDL specification to use when generating the WSDL file. I suggest putting the option on the Web Services tab of the VDB, but I am open for other suggestions. Alternatively, we could add the WSDL using both specifications in separate WSDL files and then provide a different WSDL URL to get one or the other. This approach seems like overkill to me though and would have farther reaching ramifications.
Ideally this would be completed for Westport.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] Created: (TEIIDDES-191) XSD as Relational importer has problems with child elements with many parents
by Greg Haber (JIRA)
XSD as Relational importer has problems with child elements with many parents
-----------------------------------------------------------------------------
Key: TEIIDDES-191
URL: https://jira.jboss.org/jira/browse/TEIIDDES-191
Project: Teiid Designer
Issue Type: Bug
Components: Import/Export
Affects Versions: 6.0.0
Environment: Teiid Designer 6.0.0 official (14 May 2009) release
Reporter: Greg Haber
Attachments: address.xsd, person.xsd, person2.xml, person2.xsd
I've encountered a lot of problems with the Teiid Designer XML as Relational Importer (and with its legacy ancestor) dealing with importing XSDs where a child element has multiple parents. The importer currently treats all elements throughout the XSD that have the same name and type as the same, and so models that element(s) as a single table with multiple parents, if the number of parents is above a configurable number (currently defaults to 3).
Which is all well and good in theory, but in practice it seems to hit a number of problems
1) During the import process, if the selection of document root elements is left at the default, not all needed tables are generated. See person.xsd example attached.
2) If all possible root elements are selected, it looks mostly right, but there are often extra elements in the child tables (again try with person.xsd). Plus, the tables don't actually work at runtime correctly (try using attached person2.xml as the data source - notice that you can only get to the spouse's father from Person, not to their own father).
I've also attached some other example problem XSDs - person2.xsd, and address.xsd
Now, in some cases a reasonable workaround is to up the number of allowed parents parameter, so that everything gets folded into a single table. But that isn't a general solution, as it doesn't work with things like person2.xsd.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months