June 2014 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-2993) Adding source table with quoted name results in wrong generated SQL statement

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2993?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2993: --------------------------------------- > fixed the NIS to be wrapped in d-quotes Just to make sure you mean wrapped in the quote string for the source, as it's not always double quote. So then should I mark this as deferred or just leave it open for now? > Adding source table with quoted name results in wrong generated SQL statement > ----------------------------------------------------------------------------- > > Key: TEIID-2993 > URL: https://issues.jboss.org/browse/TEIID-2993 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 6.0.0 > Reporter: Paul Richardson > Assignee: Steven Hawkins > > Cloned from TEIIDDES-2152: > 1) Created source model with simple table named "My.Quoted.Table" (including quotes > 2) Created simple virtual table and pasted: SELECT * FROM "My.Quoted.Table" > 3) Parser returned a command resulting in the SQL: SELECT * FROM My.Quoted."Table" > Parser should be able to handle quoted names properly. In this case the SQL should have been valid as is. > Confirmed that this does go right back to the Teiid parser. To confirm, the following test was included in > src/test/java/org/teiid/query/parser/TestParser.java > {code} > @Test > public void testQuotedSQLString() { > String sql = "SELECT * FROM \"My.Quoted.Table\""; //$NON-NLS-1$ > String expected = "SELECT * FROM \"MY.QUOTED.TABLE\""; //$NON-NLS-1$ > helpTest(sql, expected, null); > } > {code} > Test fails with a comparison error with the parser returning the SQL in item 3 above. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2993) Adding source table with quoted name results in wrong generated SQL statement

by Barry LaFond (JIRA)

[ https://issues.jboss.org/browse/TEIID-2993?page=com.atlassian.jira.plugin... ] Barry LaFond commented on TEIID-2993: ------------------------------------- 1) >>>> if a table name includes '.', we flag the following error: *The name (PARTSSUPPLIER.SUPPLIER_PARTS) contains the '.' delimiter. This name is required to be wrapped in double-quotes.* So we'll remove that validation/restriction since we've fixed the NIS to be wrapped in d-quotes. > Adding source table with quoted name results in wrong generated SQL statement > ----------------------------------------------------------------------------- > > Key: TEIID-2993 > URL: https://issues.jboss.org/browse/TEIID-2993 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 6.0.0 > Reporter: Paul Richardson > Assignee: Steven Hawkins > > Cloned from TEIIDDES-2152: > 1) Created source model with simple table named "My.Quoted.Table" (including quotes > 2) Created simple virtual table and pasted: SELECT * FROM "My.Quoted.Table" > 3) Parser returned a command resulting in the SQL: SELECT * FROM My.Quoted."Table" > Parser should be able to handle quoted names properly. In this case the SQL should have been valid as is. > Confirmed that this does go right back to the Teiid parser. To confirm, the following test was included in > src/test/java/org/teiid/query/parser/TestParser.java > {code} > @Test > public void testQuotedSQLString() { > String sql = "SELECT * FROM \"My.Quoted.Table\""; //$NON-NLS-1$ > String expected = "SELECT * FROM \"MY.QUOTED.TABLE\""; //$NON-NLS-1$ > helpTest(sql, expected, null); > } > {code} > Test fails with a comparison error with the parser returning the SQL in item 3 above. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2994) DDL Option properties not namespaced for salesforce

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-2994?page=com.atlassian.jira.plugin... ] Ramesh Reddy resolved TEIID-2994. --------------------------------- Labels: Beta1 (was: ) Fix Version/s: 8.7.1 8.8 Resolution: Done Added the SF prefix to the metadata properties. Since they were not being used to make decisions at runtime, no further changes were required. > DDL Option properties not namespaced for salesforce > --------------------------------------------------- > > Key: TEIID-2994 > URL: https://issues.jboss.org/browse/TEIID-2994 > Project: Teiid > Issue Type: Bug > Components: AdminApi > Affects Versions: 8.7 > Reporter: Mark Drilling > Assignee: Ramesh Reddy > Labels: Beta1 > Fix For: 8.7.1, 8.8 > > Attachments: DDLExtOptionsComparison.txt > > > The Option keys for DDL with saleforce source are not getting namespaced. This is inconsistent with other sources like excel. See attached file - comparison of two tables - Excel source vs Salesforce source. The excel keys are prefixed with a namespace teiid_excel: but the salesforce keys are not. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2981) Add an OData query parameter that caches the resultset

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2981?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2981: --------------------------------------- Would a first step enhancement be allow setting the ResultSetCacheMode on the connection via the servlet init parameters or do you need fine grained control? > Add an OData query parameter that caches the resultset > ------------------------------------------------------ > > Key: TEIID-2981 > URL: https://issues.jboss.org/browse/TEIID-2981 > Project: Teiid > Issue Type: Feature Request > Components: OData > Affects Versions: 8.7 > Reporter: John Muller > Assignee: Steven Hawkins > Priority: Minor > Labels: Caching, OData, > > The Teiid caching guide indicates that the /*+ cache */ SQL hint is neccessary in order to cache results [1] . We would like two features added to the OData support: (1) to have a query parameter that basically injects the hint into the SQL statement run against the VDB and (2) a configuration setting that turns on OData resultset caching for all result sets smaller than some size (perhaps 256 as the default) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2981) Add an OData query parameter that caches the resultset

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2981?page=com.atlassian.jira.plugin... ] Steven Hawkins edited comment on TEIID-2981 at 6/6/14 3:01 PM: --------------------------------------------------------------- Would a first step enhancement be to allow setting the ResultSetCacheMode on the connection via the servlet init parameters or do you need fine grained control? was (Author: shawkins): Would a first step enhancement be allow setting the ResultSetCacheMode on the connection via the servlet init parameters or do you need fine grained control? > Add an OData query parameter that caches the resultset > ------------------------------------------------------ > > Key: TEIID-2981 > URL: https://issues.jboss.org/browse/TEIID-2981 > Project: Teiid > Issue Type: Feature Request > Components: OData > Affects Versions: 8.7 > Reporter: John Muller > Assignee: Steven Hawkins > Priority: Minor > Labels: Caching, OData, > > The Teiid caching guide indicates that the /*+ cache */ SQL hint is neccessary in order to cache results [1] . We would like two features added to the OData support: (1) to have a query parameter that basically injects the hint into the SQL statement run against the VDB and (2) a configuration setting that turns on OData resultset caching for all result sets smaller than some size (perhaps 256 as the default) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2993) Adding source table with quoted name results in wrong generated SQL statement

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2993?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2993: --------------------------------------- > 1) Should Table names be allowed in Designer that include the '.' delimiter (i.e. no d-quotes needed) and remove the validation? >>> (thinking YES??) Should table names that include '.' be allowed - yes. And remove the validation - I'm not sure what you mean about this part. > 2) If not, then should the JDBC importer remove the "Full Qualified Names" option or create the FQN with '_' instead of '.' delimiter? >>> (thinking NO??) You can of course independently add an import option to "create simple name" that would rewrite any name as a valid unquoted ansi sql identifier, but that is not required here. > is then VALID as long as the NIS is correct Yes and that is why import always sets the name in source to an appropriately quoted (since the reserved words and the quoting scheme can very by source) value. > Adding source table with quoted name results in wrong generated SQL statement > ----------------------------------------------------------------------------- > > Key: TEIID-2993 > URL: https://issues.jboss.org/browse/TEIID-2993 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 6.0.0 > Reporter: Paul Richardson > Assignee: Steven Hawkins > > Cloned from TEIIDDES-2152: > 1) Created source model with simple table named "My.Quoted.Table" (including quotes > 2) Created simple virtual table and pasted: SELECT * FROM "My.Quoted.Table" > 3) Parser returned a command resulting in the SQL: SELECT * FROM My.Quoted."Table" > Parser should be able to handle quoted names properly. In this case the SQL should have been valid as is. > Confirmed that this does go right back to the Teiid parser. To confirm, the following test was included in > src/test/java/org/teiid/query/parser/TestParser.java > {code} > @Test > public void testQuotedSQLString() { > String sql = "SELECT * FROM \"My.Quoted.Table\""; //$NON-NLS-1$ > String expected = "SELECT * FROM \"MY.QUOTED.TABLE\""; //$NON-NLS-1$ > helpTest(sql, expected, null); > } > {code} > Test fails with a comparison error with the parser returning the SQL in item 3 above. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2993) Adding source table with quoted name results in wrong generated SQL statement

by Barry LaFond (JIRA)

[ https://issues.jboss.org/browse/TEIID-2993?page=com.atlassian.jira.plugin... ] Barry LaFond commented on TEIID-2993: ------------------------------------- Sounds good to me. 1) Should Table names be allowed in Designer that include the '.' delimiter (i.e. no d-quotes needed) and remove the validation? >>> (thinking YES??) 2) If not, then should the JDBC importer remove the "Full Qualified Names" option or create the FQN with '_' instead of '.' delimiter? >>> (thinking NO??) ... and I just verified that if I create a generic table with name *xxx.xxx* and set the SQL in a view to SELECT * FROM PARTSORACLE.xxx.xxx, the SQL is then VALID as long as the NIS is correct. > Adding source table with quoted name results in wrong generated SQL statement > ----------------------------------------------------------------------------- > > Key: TEIID-2993 > URL: https://issues.jboss.org/browse/TEIID-2993 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 6.0.0 > Reporter: Paul Richardson > Assignee: Steven Hawkins > > Cloned from TEIIDDES-2152: > 1) Created source model with simple table named "My.Quoted.Table" (including quotes > 2) Created simple virtual table and pasted: SELECT * FROM "My.Quoted.Table" > 3) Parser returned a command resulting in the SQL: SELECT * FROM My.Quoted."Table" > Parser should be able to handle quoted names properly. In this case the SQL should have been valid as is. > Confirmed that this does go right back to the Teiid parser. To confirm, the following test was included in > src/test/java/org/teiid/query/parser/TestParser.java > {code} > @Test > public void testQuotedSQLString() { > String sql = "SELECT * FROM \"My.Quoted.Table\""; //$NON-NLS-1$ > String expected = "SELECT * FROM \"MY.QUOTED.TABLE\""; //$NON-NLS-1$ > helpTest(sql, expected, null); > } > {code} > Test fails with a comparison error with the parser returning the SQL in item 3 above. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2994) DDL Option properties not namespaced for salesforce

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-2994?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-2994: ------------------------------------- >If there is no NS prefix in the OPTIONS() keys, then how is the DDL going to be tied to a specific Translator type? yes, extension properties and translator go together for translator. That is why SteveH has been critical of design with namespaces as it is adding more issues than it is solving. > Backwards compatibility can be achieved only if a NS is provided on the SF OPTIONS() key values, just like any other. I am not sure what you mean by here. Here is my concern, currently translator has for ages has been reading these properties without a namespace on the property name, if we add it now, if a user gets their old vdb and deploys into to new runtime, it will fail to recognize those values. However, there are couple things specific to this translator, * I am not sure why original author defined these metadata properties, but when I looked at them in the code they are being used at all. So it does not matter, so I could add the namespace * I could add compensating code to look both with name space and without thus I did not reject the issue, i will fix accordingly. Do we need this also in 8.7.1? > DDL Option properties not namespaced for salesforce > --------------------------------------------------- > > Key: TEIID-2994 > URL: https://issues.jboss.org/browse/TEIID-2994 > Project: Teiid > Issue Type: Bug > Components: AdminApi > Affects Versions: 8.7 > Reporter: Mark Drilling > Assignee: Ramesh Reddy > Attachments: DDLExtOptionsComparison.txt > > > The Option keys for DDL with saleforce source are not getting namespaced. This is inconsistent with other sources like excel. See attached file - comparison of two tables - Excel source vs Salesforce source. The excel keys are prefixed with a namespace teiid_excel: but the salesforce keys are not. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2994) DDL Option properties not namespaced for salesforce

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2994?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2994: --------------------------------------- > Backwards compatibility can be achieved only if a NS is provided on the SF OPTIONS() key values, just like any other. Ramesh means backwards compatibility from a runtime perspective where namespaces was not previously used. The answer there is yes, the logic already supports checking for qualified and unqualified property keys. >From the example comparison, I don't see the translator using supportsDelete, etc. Only "Supports Query" and "Supports Retrieve" > DDL Option properties not namespaced for salesforce > --------------------------------------------------- > > Key: TEIID-2994 > URL: https://issues.jboss.org/browse/TEIID-2994 > Project: Teiid > Issue Type: Bug > Components: AdminApi > Affects Versions: 8.7 > Reporter: Mark Drilling > Assignee: Ramesh Reddy > Attachments: DDLExtOptionsComparison.txt > > > The Option keys for DDL with saleforce source are not getting namespaced. This is inconsistent with other sources like excel. See attached file - comparison of two tables - Excel source vs Salesforce source. The excel keys are prefixed with a namespace teiid_excel: but the salesforce keys are not. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2980) Expose sequences as arrays in XMLTABLE construct

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2980?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2980: --------------------------------------- After double checking the spec and other implementations, this is not common or mandated behavior. However I think it is straight-forward enough that it's still worth while. > Expose sequences as arrays in XMLTABLE construct > ------------------------------------------------- > > Key: TEIID-2980 > URL: https://issues.jboss.org/browse/TEIID-2980 > Project: Teiid > Issue Type: Feature Request > Reporter: Ramesh Reddy > Assignee: Steven Hawkins > > we should allow xmltable to select sequences as array values. The array then could be manipulated in any way needed -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues June 2014