May 2015 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-3473) Selecting RAW(16) column via OData errors

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-3473?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-3473: --------------------------------- Fix Version/s: 8.7.3 > Selecting RAW(16) column via OData errors > ----------------------------------------- > > Key: TEIID-3473 > URL: https://issues.jboss.org/browse/TEIID-3473 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 8.7 > Reporter: Debbie Steigner > Assignee: Steven Hawkins > Fix For: 8.7.1.6_2, 8.11, 8.7.3 > > > When selecting a RAW(16) column via OData, a runtime error is thrown w/ the following message: > http://superdrake:8080/odata/Medbus/reqtracking.query?$format=json > { > "error": { > "code" : "ServerErrorException", > "message": { > "lang": "en-US", > "value": "[B cannot be cast to org.teiid.core.types.BinaryType" > } > } > } -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3271) JDBC Translator | Incorrect Update count reported on Batched Update Execution

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-3271?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-3271: --------------------------------- Fix Version/s: 8.7.3 > JDBC Translator | Incorrect Update count reported on Batched Update Execution > ----------------------------------------------------------------------------- > > Key: TEIID-3271 > URL: https://issues.jboss.org/browse/TEIID-3271 > Project: Teiid > Issue Type: Bug > Components: JDBC Connector > Reporter: Shiveeta Mattoo > Assignee: Steven Hawkins > Labels: Batch-Updates, JDBC-Transator > Fix For: 8.10, 8.7.3 > > > Issue is related to Batched updates scenario. > Typically, the executeBatch() returns an array of integers, and each element of the array represents the update count for the respective update statement. > However in case of Teiid JDBC Translator, over and above this, we are processing the array to return a sum of all the elements as in seen in JDBCUpdateExecution -> executeTranslatedCommand method > int[] results = pstatement.executeBatch(); > for (int i=0; i<results.length; i++) { > updateCount += results[i]; > } > The bug is logged to fix this to meet the standard behaviour > Refer thread https://developer.jboss.org/message/914596?et=watches.email.thread#914596 for details -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3358) Issues with entity set names

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-3358?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-3358: --------------------------------- Fix Version/s: 8.7.3 > Issues with entity set names > ---------------------------- > > Key: TEIID-3358 > URL: https://issues.jboss.org/browse/TEIID-3358 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 8.7 > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Labels: Alpha1 > Fix For: 8.7.1.6_2, 8.11, 8.7.3 > > > The entity set name used for sql generation should be the fully qualified name. If there is for example two table with the same names in schemas visible to odata, but one of the tables does not have a key, then an ambiguous name exception will be thrown if an odata url is used with only the base table name. > It also appears that the URI link in the results metadata uses the non-qualified table name, which will have issues in the scenario above. > We may also need to document or add an additional check for ambiguity as the OData4j findEdmEntitySet logic will return the first matching entity, which is generally against our approach to resolving. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3489) Can a function be added to filter certain ASCII chars below 31 and above 127 out of an XML Document

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3489?page=com.atlassian.jira.plugin... ] Steven Hawkins reassigned TEIID-3489: ------------------------------------- Issue Type: Enhancement (was: Feature Request) Fix Version/s: 8.12 Assignee: (was: Steven Hawkins) > Can a function be added to filter certain ASCII chars below 31 and above 127 out of an XML Document > --------------------------------------------------------------------------------------------------- > > Key: TEIID-3489 > URL: https://issues.jboss.org/browse/TEIID-3489 > Project: Teiid > Issue Type: Enhancement > Components: Query Engine > Reporter: Debbie Steigner > Priority: Minor > Fix For: 8.12 > > > Add a function in Teiid to filter off all ASCII chars below 31 and above 127. > web service data source that contains control characters due to data entered by copy and paste the text from another system. > The characters in this instance were the print control chars ASCII 28 and 29, File Separator and Group Separator respectively. These are used for formatting in older systems. Unfortunately, the XML standard prohibits the processing of all ASCII characters below 31 apart from Tab, Line Feed and Carriage Return which are permissible. Also, ASCII chars above 127 to 255 will also cause XML parsers to crash. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3436) Add array type support to the odata translator

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3436?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3436: --------------------------------------- Ok after the that last change, I'm back to where I started with this. AtomFeedFormatParser.parseProperties cannot resolve collection types. Also XmlFormatWriter converts the collection type to bag, rather than list. Would it make a difference if we changed the translator to request json rather than atom? > Add array type support to the odata translator > ---------------------------------------------- > > Key: TEIID-3436 > URL: https://issues.jboss.org/browse/TEIID-3436 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Reporter: Steven Hawkins > > Arrays of basic types in odata responses should be convertible into a runtime array type. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3489) Can a function be added to filter certain ASCII chars below 31 and above 127 out of an XML Document

by Debbie Steigner (JIRA)

[ https://issues.jboss.org/browse/TEIID-3489?page=com.atlassian.jira.plugin... ] Debbie Steigner commented on TEIID-3489: ---------------------------------------- It's happening when trying to parse the result as xml, receives: Error: Remote org.teiid.api.exception.query.ExpressionEvaluationException: Unable to evaluate XMLPARSE(DOCUMENT f.result): Value is not valid XML SQLState: 50000 ErrorCode: 0 > Can a function be added to filter certain ASCII chars below 31 and above 127 out of an XML Document > --------------------------------------------------------------------------------------------------- > > Key: TEIID-3489 > URL: https://issues.jboss.org/browse/TEIID-3489 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Reporter: Debbie Steigner > Assignee: Steven Hawkins > Priority: Minor > > Add a function in Teiid to filter off all ASCII chars below 31 and above 127. > web service data source that contains control characters due to data entered by copy and paste the text from another system. > The characters in this instance were the print control chars ASCII 28 and 29, File Separator and Group Separator respectively. These are used for formatting in older systems. Unfortunately, the XML standard prohibits the processing of all ASCII characters below 31 apart from Tab, Line Feed and Carriage Return which are permissible. Also, ASCII chars above 127 to 255 will also cause XML parsers to crash. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3489) Can a function be added to filter certain ASCII chars below 31 and above 127 out of an XML Document

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3489?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3489: --------------------------------------- So is this an issue down in the web service translator - for example does this need to happen when the the translator is parsing a soap response. Or is this from just a http request and is happening trying to parse the blob result as xml? > Can a function be added to filter certain ASCII chars below 31 and above 127 out of an XML Document > --------------------------------------------------------------------------------------------------- > > Key: TEIID-3489 > URL: https://issues.jboss.org/browse/TEIID-3489 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Reporter: Debbie Steigner > Assignee: Steven Hawkins > Priority: Minor > > Add a function in Teiid to filter off all ASCII chars below 31 and above 127. > web service data source that contains control characters due to data entered by copy and paste the text from another system. > The characters in this instance were the print control chars ASCII 28 and 29, File Separator and Group Separator respectively. These are used for formatting in older systems. Unfortunately, the XML standard prohibits the processing of all ASCII characters below 31 apart from Tab, Line Feed and Carriage Return which are permissible. Also, ASCII chars above 127 to 255 will also cause XML parsers to crash. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3489) Can a function be added to filter certain ASCII chars below 31 and above 127 out of an XML Document

by Debbie Steigner (JIRA)

[ https://issues.jboss.org/browse/TEIID-3489?page=com.atlassian.jira.plugin... ] Debbie Steigner commented on TEIID-3489: ---------------------------------------- Their web service datasource response document has invalid characters and the source provider will not correct it, so they want a way to parse out the invalid ASCII characters. So they would want to convert to string and parse out the characters from anywhere in the document. > Can a function be added to filter certain ASCII chars below 31 and above 127 out of an XML Document > --------------------------------------------------------------------------------------------------- > > Key: TEIID-3489 > URL: https://issues.jboss.org/browse/TEIID-3489 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Reporter: Debbie Steigner > Assignee: Steven Hawkins > Priority: Minor > > Add a function in Teiid to filter off all ASCII chars below 31 and above 127. > web service data source that contains control characters due to data entered by copy and paste the text from another system. > The characters in this instance were the print control chars ASCII 28 and 29, File Separator and Group Separator respectively. These are used for formatting in older systems. Unfortunately, the XML standard prohibits the processing of all ASCII characters below 31 apart from Tab, Line Feed and Carriage Return which are permissible. Also, ASCII chars above 127 to 255 will also cause XML parsers to crash. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3489) Can a function be added to filter certain ASCII chars below 31 and above 127 out of an XML Document

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3489?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3489: --------------------------------------- I couldn't ascertain at what point this function will be used. Is this for converting a clob/blob into xml? Or is this for sending a value out for inclusion into an xml document? > Can a function be added to filter certain ASCII chars below 31 and above 127 out of an XML Document > --------------------------------------------------------------------------------------------------- > > Key: TEIID-3489 > URL: https://issues.jboss.org/browse/TEIID-3489 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Reporter: Debbie Steigner > Assignee: Steven Hawkins > Priority: Minor > > Add a function in Teiid to filter off all ASCII chars below 31 and above 127. > web service data source that contains control characters due to data entered by copy and paste the text from another system. > The characters in this instance were the print control chars ASCII 28 and 29, File Separator and Group Separator respectively. These are used for formatting in older systems. Unfortunately, the XML standard prohibits the processing of all ASCII characters below 31 apart from Tab, Line Feed and Carriage Return which are permissible. Also, ASCII chars above 127 to 255 will also cause XML parsers to crash. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3486) Add array data type support to Loopback Translator

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3486?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-3486. ----------------------------------- Fix Version/s: 8.11 Resolution: Done Made several changes under this: Array now returns it's actual type, rather than just object. Changed the logic to not use asynch logic when a delay is specified Added dummy array value support > Add array data type support to Loopback Translator > -------------------------------------------------- > > Key: TEIID-3486 > URL: https://issues.jboss.org/browse/TEIID-3486 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Reporter: Ramesh Reddy > Assignee: Steven Hawkins > Priority: Minor > Fix For: 8.11 > > > Adding the array data type support will be nice for testing purposes. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues May 2015