March 2018 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-5281) Issue with concatenating null strings with OData translator

by Jan Martiska (JIRA)

[ https://issues.jboss.org/browse/TEIID-5281?page=com.atlassian.jira.plugin... ] Jan Martiska commented on TEIID-5281: ------------------------------------- No, but a query with {noformat} filter=concat(s1,s2) eq '10' {noformat} will return rows where s1='10' and s2=null, which I assume it should not. > Issue with concatenating null strings with OData translator > ----------------------------------------------------------- > > Key: TEIID-5281 > URL: https://issues.jboss.org/browse/TEIID-5281 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 8.12.11.6_4 > Reporter: Jan Martiska > Assignee: Steven Hawkins > Priority: Minor > > There is a difference in behavior of {{CONCAT(x,y)}} function in Teiid SQL and the {{concat(x,y)}} filtering function in OData - the SQL function will return null if one of the arguments is null, but the OData function will return the non-null argument in this case. > This leads to some peculiar behavior that for rows where A='10' and B=null, the query > {noformat} > SELECT concat(A, B) = '10' > FROM BQT1.SmallA > WHERE concat(A, B) = '10'; > {noformat} > will return a row containing {{false}}, because the expression in the SELECT clause will be evaluated by Teiid, whereas the one in the WHERE clause will be evaluated by the OData {{concat}} function. > This is against the documented behavior of Teiid's {{CONCAT}} function, because such row should not be returned at all. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (TEIID-5281) Issue with concatenating null strings with OData translator

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-5281?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-5281: ------------------------------------- Do you get a parse error with "concat('string', null)"? > Issue with concatenating null strings with OData translator > ----------------------------------------------------------- > > Key: TEIID-5281 > URL: https://issues.jboss.org/browse/TEIID-5281 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 8.12.11.6_4 > Reporter: Jan Martiska > Assignee: Steven Hawkins > Priority: Minor > > There is a difference in behavior of {{CONCAT(x,y)}} function in Teiid SQL and the {{concat(x,y)}} filtering function in OData - the SQL function will return null if one of the arguments is null, but the OData function will return the non-null argument in this case. > This leads to some peculiar behavior that for rows where A='10' and B=null, the query > {noformat} > SELECT concat(A, B) = '10' > FROM BQT1.SmallA > WHERE concat(A, B) = '10'; > {noformat} > will return a row containing {{false}}, because the expression in the SELECT clause will be evaluated by Teiid, whereas the one in the WHERE clause will be evaluated by the OData {{concat}} function. > This is against the documented behavior of Teiid's {{CONCAT}} function, because such row should not be returned at all. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (TEIID-5281) Issue with concatenating null strings with OData translator

by Jan Martiska (JIRA)

[ https://issues.jboss.org/browse/TEIID-5281?page=com.atlassian.jira.plugin... ] Jan Martiska commented on TEIID-5281: ------------------------------------- Oh, I missed that paragraph. In that case it seems that Olingo is doing it incorrectly, because it won't treat concat('string', null) as null. > Issue with concatenating null strings with OData translator > ----------------------------------------------------------- > > Key: TEIID-5281 > URL: https://issues.jboss.org/browse/TEIID-5281 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 8.12.11.6_4 > Reporter: Jan Martiska > Assignee: Steven Hawkins > Priority: Minor > > There is a difference in behavior of {{CONCAT(x,y)}} function in Teiid SQL and the {{concat(x,y)}} filtering function in OData - the SQL function will return null if one of the arguments is null, but the OData function will return the non-null argument in this case. > This leads to some peculiar behavior that for rows where A='10' and B=null, the query > {noformat} > SELECT concat(A, B) = '10' > FROM BQT1.SmallA > WHERE concat(A, B) = '10'; > {noformat} > will return a row containing {{false}}, because the expression in the SELECT clause will be evaluated by Teiid, whereas the one in the WHERE clause will be evaluated by the OData {{concat}} function. > This is against the documented behavior of Teiid's {{CONCAT}} function, because such row should not be returned at all. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (TEIID-5281) Issue with concatenating null strings with OData translator

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-5281?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-5281: ------------------------------------- Based on http://docs.oasis-open.org/odata/odata/v4.0/errata03/os/complete/part2-ur... section "5.1.1.4 Canonical Functions" it says if one of the parameters is null the result should be null too, matching Teiid's behavior. So is there a difference in behavior right now? > Issue with concatenating null strings with OData translator > ----------------------------------------------------------- > > Key: TEIID-5281 > URL: https://issues.jboss.org/browse/TEIID-5281 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 8.12.11.6_4 > Reporter: Jan Martiska > Assignee: Steven Hawkins > Priority: Minor > > There is a difference in behavior of {{CONCAT(x,y)}} function in Teiid SQL and the {{concat(x,y)}} filtering function in OData - the SQL function will return null if one of the arguments is null, but the OData function will return the non-null argument in this case. > This leads to some peculiar behavior that for rows where A='10' and B=null, the query > {noformat} > SELECT concat(A, B) = '10' > FROM BQT1.SmallA > WHERE concat(A, B) = '10'; > {noformat} > will return a row containing {{false}}, because the expression in the SELECT clause will be evaluated by Teiid, whereas the one in the WHERE clause will be evaluated by the OData {{concat}} function. > This is against the documented behavior of Teiid's {{CONCAT}} function, because such row should not be returned at all. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (TEIID-5281) Issue with concatenating null strings with OData translator

by Jan Martiska (JIRA)

[ https://issues.jboss.org/browse/TEIID-5281?page=com.atlassian.jira.plugin... ] Jan Martiska commented on TEIID-5281: ------------------------------------- Well my quite contrived testing scenario is that I'm exposing a CSV file-backed VDB over OData and then I consume that OData to construct a different VDB (on the same Teiid instance) which I'm then accessing using JDBC. You're right, I can't find anything in the OData spec that mandates this behavior of the concat function. In that case should we consider changing the implementation in Olingo? Other option is to work around this somehow in Teiid. > Issue with concatenating null strings with OData translator > ----------------------------------------------------------- > > Key: TEIID-5281 > URL: https://issues.jboss.org/browse/TEIID-5281 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 8.12.11.6_4 > Reporter: Jan Martiska > Assignee: Steven Hawkins > Priority: Minor > > There is a difference in behavior of {{CONCAT(x,y)}} function in Teiid SQL and the {{concat(x,y)}} filtering function in OData - the SQL function will return null if one of the arguments is null, but the OData function will return the non-null argument in this case. > This leads to some peculiar behavior that for rows where A='10' and B=null, the query > {noformat} > SELECT concat(A, B) = '10' > FROM BQT1.SmallA > WHERE concat(A, B) = '10'; > {noformat} > will return a row containing {{false}}, because the expression in the SELECT clause will be evaluated by Teiid, whereas the one in the WHERE clause will be evaluated by the OData {{concat}} function. > This is against the documented behavior of Teiid's {{CONCAT}} function, because such row should not be returned at all. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (TEIID-5282) Add source fully qualified name extension properties

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5282?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5282: --------------------------------------- To flesh out the proposal: We will add teiid_rel:source_fqn. The name and value pairs in an fqn will be url encoded and use the format name=value/name=value... We can worry about internationalization of the names later if needed. We will also add teiid_rel:source_attributes. The value will be a json object (map) of additional source metadata. In particular table_type, but could also include owner, etc. Obviously the keys/values here will be source specific, so there may need to be additional metadata captured about them. It doesn't seem imperative that we add a property to columns as their name will match the source in most circumstances - however it will not when there is a name collusion (due to case insensitivity) or if it contains a '.' character. > Add source fully qualified name extension properties > ---------------------------------------------------- > > Key: TEIID-5282 > URL: https://issues.jboss.org/browse/TEIID-5282 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 10.2 > > > To support TEIIDTOOLS-362 and in general the lookup of source objects by a name other than the Teiid name, we need to add a fully qualified name property. > The proposal would look like an ldap name containing both the name/parts: > create foreign table "schemaName.tableName" (...) options ('teiid_rel:fqn' 'catalog:catalogName/schema:schemaName/table:tableName'); > The names will reflect the constructs for each source: > google: 'worksheet:name/sheet:name' > salesforce: 'sObject:name' > etc. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (TEIID-5282) Add source fully qualified name extension properties

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5282?page=com.atlassian.jira.plugin... ] Work on TEIID-5282 started by Steven Hawkins. --------------------------------------------- > Add source fully qualified name extension properties > ---------------------------------------------------- > > Key: TEIID-5282 > URL: https://issues.jboss.org/browse/TEIID-5282 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 10.2 > > > To support TEIIDTOOLS-362 and in general the lookup of source objects by a name other than the Teiid name, we need to add a fully qualified name property. > The proposal would look like an ldap name containing both the name/parts: > create foreign table "schemaName.tableName" (...) options ('teiid_rel:fqn' 'catalog:catalogName/schema:schemaName/table:tableName'); > The names will reflect the constructs for each source: > google: 'worksheet:name/sheet:name' > salesforce: 'sObject:name' > etc. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (TEIID-5280) OData4 translator: disappearing negation when using 'in' predicate

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5280?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5280. ----------------------------------- Fix Version/s: 10.0.4 10.2 10.1.2 Resolution: Done Removed translator support for in as the engine will create the appropriate conjunct or disjunct. > OData4 translator: disappearing negation when using 'in' predicate > ------------------------------------------------------------------ > > Key: TEIID-5280 > URL: https://issues.jboss.org/browse/TEIID-5280 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 8.12.11.6_4 > Reporter: Jan Martiska > Assignee: Steven Hawkins > Fix For: 10.0.4, 10.2, 10.1.2 > > > Suppose this query against an OData4-backed view: > {noformat} > SELECT intkey FROM bqt1.smalla WHERE NOT (intkey IN (1, 2, 3)) > {noformat} > This is translated to a filter: > {noformat} > filter=intkey eq 1 or intkey eq 2 or intkey eq 3 > {noformat} > The NOT operator disappeared and this will return rows where intkey is equal to 1, 2 or 3. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (TEIID-5278) Wrong indexing with SUBSTRING function and OData4 translator

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5278?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5278. ----------------------------------- Fix Version/s: 10.0.4 10.2 10.1.2 Resolution: Done Added a function modifier to adjust the index. > Wrong indexing with SUBSTRING function and OData4 translator > ------------------------------------------------------------ > > Key: TEIID-5278 > URL: https://issues.jboss.org/browse/TEIID-5278 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 8.12.11.6_4 > Reporter: Jan Martiska > Assignee: Steven Hawkins > Fix For: 10.0.4, 10.2, 10.1.2 > > > SQL {{SUBSTRING}} function indexes strings from 1, but OData {{substring}} filtering function indexes from zero. This needs to be taken into account. > Currently a query containing {{WHERE SUBSTRING(stringkey, 1, 1) = 'x'}} will return items where the second character is x, but it should return rows where the first character is x. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (TEIID-5279) OData4 translator incorrecly translates modulo function

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5279?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-5279: ---------------------------------- Fix Version/s: 10.0.4 10.1.2 > OData4 translator incorrecly translates modulo function > ------------------------------------------------------- > > Key: TEIID-5279 > URL: https://issues.jboss.org/browse/TEIID-5279 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 8.12.11.6_4 > Reporter: Jan Martiska > Assignee: Ramesh Reddy > Fix For: 10.0.4, 10.2, 10.1.2 > > > With an OData4 translator, the {{modulo}} function is translated incorrectly: > {{WHERE MOD(number, 11) = 3}} is translated to {{filter=mod(number,11) eq 3}} > but in OData spec, {{mod}} is an infix function, so the filter should be {{filter=number mod 11 eq 3}} > See http://docs.oasis-open.org/odata/odata/v4.0/odata-v4.0-part2-url-conventi... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues March 2018