[JBoss JIRA] (TEIID-3842) Teiid's query's explain not consistence with other Database
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-3842?page=com.atlassian.jira.plugin... ]
Kylin Soong updated TEIID-3842:
-------------------------------
Description:
h2. The way to get execution plan is not consistence with others
For most of RDBMS(Oracle, Mysql), the execution plan get via SQL query
{code}
explain select ...
{code}
But in Teiid, we need use Teiid API, and need enable showplan in advance:
{code}
statement.execute("set showplan on");
ResultSet rs = statement.executeQuery("select ...");
TeiidStatement tstatement = statement.unwrap(TeiidStatement.class);
PlanNode queryPlan = tstatement.getPlanDescription();
System.out.println(queryPlan);
{code}
Cache Hint can be added as prefix, so I think we can enhance that show plan also as prefix, in order for consistence with others.
h2. The plan structure is too complex
[1] is the query plan of dynamicvdb-datafederation which is 2 datasources' federation, it long, complex, for the users/customers, it's not easy for them to understand. So can we enhance that simplify the output, like add a format option that can output as matrix/table.
[1] dynamicvdb-datafederation's 'select * from Stock' query plan
{code}
ProjectNode
+ Relational Node ID:0
+ Output Columns:
0: product_id (integer)
1: symbol (string)
2: price (bigdecimal)
3: company_name (string)
+ Statistics:
0: Node Output Rows: 9
1: Node Next Batch Process Time: 0
2: Node Cumulative Next Batch Process Time: 12
3: Node Cumulative Process Time: 21
4: Node Next Batch Calls: 3
5: Node Blocks: 2
+ Cost Estimates:Estimated Node Cardinality: -1.0
+ Child 0:
JoinNode
+ Relational Node ID:1
+ Output Columns:
0: ID (integer)
1: symbol (string)
2: price (bigdecimal)
3: COMPANY_NAME (string)
+ Statistics:
0: Node Output Rows: 9
1: Node Next Batch Process Time: 4
2: Node Cumulative Next Batch Process Time: 12
3: Node Cumulative Process Time: 21
4: Node Next Batch Calls: 3
5: Node Blocks: 2
+ Cost Estimates:Estimated Node Cardinality: -1.0
+ Child 0:
JoinNode
+ Relational Node ID:2
+ Output Columns:
0: symbol (string)
1: price (bigdecimal)
+ Statistics:
0: Node Output Rows: 10
1: Node Next Batch Process Time: 2
2: Node Cumulative Next Batch Process Time: 7
3: Node Cumulative Process Time: 7
4: Node Next Batch Calls: 2
5: Node Blocks: 1
+ Cost Estimates:Estimated Node Cardinality: -1.0
+ Child 0:
ProjectNode
+ Relational Node ID:3
+ Output Columns:file (clob)
+ Statistics:
0: Node Output Rows: 1
1: Node Next Batch Process Time: 0
2: Node Cumulative Next Batch Process Time: 2
3: Node Cumulative Process Time: 2
4: Node Next Batch Calls: 1
5: Node Blocks: 0
+ Cost Estimates:Estimated Node Cardinality: -1.0
+ Child 0:
AccessNode
+ Relational Node ID:4
+ Output Columns:
0: file (clob)
1: filePath (string)
+ Statistics:
0: Node Output Rows: 1
1: Node Next Batch Process Time: 2
2: Node Cumulative Next Batch Process Time: 2
3: Node Cumulative Process Time: 2
4: Node Next Batch Calls: 1
5: Node Blocks: 0
+ Cost Estimates:Estimated Node Cardinality: -1.0
+ Query:EXEC MarketData.getTextFiles('*.txt')
+ Model Name:MarketData
+ Select Columns:MarketData.getTextFiles.file
+ Child 1:
TextTableNode
+ Relational Node ID:5
+ Output Columns:
0: symbol (string)
1: price (bigdecimal)
+ Statistics:
0: Node Output Rows: 10
1: Node Next Batch Process Time: 3
2: Node Cumulative Next Batch Process Time: 3
3: Node Cumulative Process Time: 3
4: Node Next Batch Calls: 2
5: Node Blocks: 1
+ Cost Estimates:Estimated Node Cardinality: -1.0
+ Table Function:TEXTTABLE(f.file COLUMNS symbol string, price bigdecimal HEADER) AS SP
+ Join Strategy:NESTED TABLE JOIN
+ Join Type:CROSS JOIN
+ Join Criteria
+ Child 1:
AccessNode
+ Relational Node ID:6
+ Output Columns:
0: SYMBOL (string)
1: ID (integer)
2: COMPANY_NAME (string)
+ Statistics:
0: Node Output Rows: 25
1: Node Next Batch Process Time: 1
2: Node Cumulative Next Batch Process Time: 1
3: Node Cumulative Process Time: 17
4: Node Next Batch Calls: 5
5: Node Blocks: 4
+ Cost Estimates:Estimated Node Cardinality: -1.0
+ Query:SELECT g_0.SYMBOL AS c_0, g_0.ID AS c_1, g_0.COMPANY_NAME AS c_2 FROM Accounts.PRODUCT AS g_0 ORDER BY c_0
+ Model Name:Accounts
+ Join Strategy:ENHANCED SORT JOIN RAN AS SORT MERGE (SORT/ALREADY_SORTED)
+ Join Type:INNER JOIN
+ Join Criteria:SP.symbol=A.SYMBOL
+ Select Columns:
0: A.ID AS product_id
1: SP.symbol
2: SP.price
3: A.COMPANY_NAME AS company_name
+ Data Bytes Sent:0
+ Planning Time:128
{code}
was:
h2. The way to get execution plan is not consistence with others
For most of RDBMS(Oracle, Mysql), the execution plan get via SQL query
{code}
explain select ...
{code}
But in Teiid, we need use Teiid API, and need enable showplan in advance:
{code}
statement.execute("set showplan on");
ResultSet rs = statement.executeQuery("select ...");
TeiidStatement tstatement = statement.unwrap(TeiidStatement.class);
PlanNode queryPlan = tstatement.getPlanDescription();
System.out.println(queryPlan);
{code}
Cache Hint can be added as prefix, so I think we can enhance that show plan also as prefix, in order for consistence with others.
h2. The plan structure is too complex
[1] is the query plan of dynamicvdb-datafederation which is 2 datasources' federation, it long, complex, for the users/customers, it's not easy for then to understand. So can we enhance that simplify the output, like add a format option that can output as matrix/table.
[1] dynamicvdb-datafederation's 'select * from Stock' query plan
{code}
ProjectNode
+ Relational Node ID:0
+ Output Columns:
0: product_id (integer)
1: symbol (string)
2: price (bigdecimal)
3: company_name (string)
+ Statistics:
0: Node Output Rows: 9
1: Node Next Batch Process Time: 0
2: Node Cumulative Next Batch Process Time: 12
3: Node Cumulative Process Time: 21
4: Node Next Batch Calls: 3
5: Node Blocks: 2
+ Cost Estimates:Estimated Node Cardinality: -1.0
+ Child 0:
JoinNode
+ Relational Node ID:1
+ Output Columns:
0: ID (integer)
1: symbol (string)
2: price (bigdecimal)
3: COMPANY_NAME (string)
+ Statistics:
0: Node Output Rows: 9
1: Node Next Batch Process Time: 4
2: Node Cumulative Next Batch Process Time: 12
3: Node Cumulative Process Time: 21
4: Node Next Batch Calls: 3
5: Node Blocks: 2
+ Cost Estimates:Estimated Node Cardinality: -1.0
+ Child 0:
JoinNode
+ Relational Node ID:2
+ Output Columns:
0: symbol (string)
1: price (bigdecimal)
+ Statistics:
0: Node Output Rows: 10
1: Node Next Batch Process Time: 2
2: Node Cumulative Next Batch Process Time: 7
3: Node Cumulative Process Time: 7
4: Node Next Batch Calls: 2
5: Node Blocks: 1
+ Cost Estimates:Estimated Node Cardinality: -1.0
+ Child 0:
ProjectNode
+ Relational Node ID:3
+ Output Columns:file (clob)
+ Statistics:
0: Node Output Rows: 1
1: Node Next Batch Process Time: 0
2: Node Cumulative Next Batch Process Time: 2
3: Node Cumulative Process Time: 2
4: Node Next Batch Calls: 1
5: Node Blocks: 0
+ Cost Estimates:Estimated Node Cardinality: -1.0
+ Child 0:
AccessNode
+ Relational Node ID:4
+ Output Columns:
0: file (clob)
1: filePath (string)
+ Statistics:
0: Node Output Rows: 1
1: Node Next Batch Process Time: 2
2: Node Cumulative Next Batch Process Time: 2
3: Node Cumulative Process Time: 2
4: Node Next Batch Calls: 1
5: Node Blocks: 0
+ Cost Estimates:Estimated Node Cardinality: -1.0
+ Query:EXEC MarketData.getTextFiles('*.txt')
+ Model Name:MarketData
+ Select Columns:MarketData.getTextFiles.file
+ Child 1:
TextTableNode
+ Relational Node ID:5
+ Output Columns:
0: symbol (string)
1: price (bigdecimal)
+ Statistics:
0: Node Output Rows: 10
1: Node Next Batch Process Time: 3
2: Node Cumulative Next Batch Process Time: 3
3: Node Cumulative Process Time: 3
4: Node Next Batch Calls: 2
5: Node Blocks: 1
+ Cost Estimates:Estimated Node Cardinality: -1.0
+ Table Function:TEXTTABLE(f.file COLUMNS symbol string, price bigdecimal HEADER) AS SP
+ Join Strategy:NESTED TABLE JOIN
+ Join Type:CROSS JOIN
+ Join Criteria
+ Child 1:
AccessNode
+ Relational Node ID:6
+ Output Columns:
0: SYMBOL (string)
1: ID (integer)
2: COMPANY_NAME (string)
+ Statistics:
0: Node Output Rows: 25
1: Node Next Batch Process Time: 1
2: Node Cumulative Next Batch Process Time: 1
3: Node Cumulative Process Time: 17
4: Node Next Batch Calls: 5
5: Node Blocks: 4
+ Cost Estimates:Estimated Node Cardinality: -1.0
+ Query:SELECT g_0.SYMBOL AS c_0, g_0.ID AS c_1, g_0.COMPANY_NAME AS c_2 FROM Accounts.PRODUCT AS g_0 ORDER BY c_0
+ Model Name:Accounts
+ Join Strategy:ENHANCED SORT JOIN RAN AS SORT MERGE (SORT/ALREADY_SORTED)
+ Join Type:INNER JOIN
+ Join Criteria:SP.symbol=A.SYMBOL
+ Select Columns:
0: A.ID AS product_id
1: SP.symbol
2: SP.price
3: A.COMPANY_NAME AS company_name
+ Data Bytes Sent:0
+ Planning Time:128
{code}
> Teiid's query's explain not consistence with other Database
> ------------------------------------------------------------
>
> Key: TEIID-3842
> URL: https://issues.jboss.org/browse/TEIID-3842
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Affects Versions: 9.x
> Reporter: Kylin Soong
> Assignee: Kylin Soong
> Fix For: 9.x
>
>
> h2. The way to get execution plan is not consistence with others
> For most of RDBMS(Oracle, Mysql), the execution plan get via SQL query
> {code}
> explain select ...
> {code}
> But in Teiid, we need use Teiid API, and need enable showplan in advance:
> {code}
> statement.execute("set showplan on");
> ResultSet rs = statement.executeQuery("select ...");
> TeiidStatement tstatement = statement.unwrap(TeiidStatement.class);
> PlanNode queryPlan = tstatement.getPlanDescription();
> System.out.println(queryPlan);
> {code}
> Cache Hint can be added as prefix, so I think we can enhance that show plan also as prefix, in order for consistence with others.
> h2. The plan structure is too complex
> [1] is the query plan of dynamicvdb-datafederation which is 2 datasources' federation, it long, complex, for the users/customers, it's not easy for them to understand. So can we enhance that simplify the output, like add a format option that can output as matrix/table.
> [1] dynamicvdb-datafederation's 'select * from Stock' query plan
> {code}
> ProjectNode
> + Relational Node ID:0
> + Output Columns:
> 0: product_id (integer)
> 1: symbol (string)
> 2: price (bigdecimal)
> 3: company_name (string)
> + Statistics:
> 0: Node Output Rows: 9
> 1: Node Next Batch Process Time: 0
> 2: Node Cumulative Next Batch Process Time: 12
> 3: Node Cumulative Process Time: 21
> 4: Node Next Batch Calls: 3
> 5: Node Blocks: 2
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Child 0:
> JoinNode
> + Relational Node ID:1
> + Output Columns:
> 0: ID (integer)
> 1: symbol (string)
> 2: price (bigdecimal)
> 3: COMPANY_NAME (string)
> + Statistics:
> 0: Node Output Rows: 9
> 1: Node Next Batch Process Time: 4
> 2: Node Cumulative Next Batch Process Time: 12
> 3: Node Cumulative Process Time: 21
> 4: Node Next Batch Calls: 3
> 5: Node Blocks: 2
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Child 0:
> JoinNode
> + Relational Node ID:2
> + Output Columns:
> 0: symbol (string)
> 1: price (bigdecimal)
> + Statistics:
> 0: Node Output Rows: 10
> 1: Node Next Batch Process Time: 2
> 2: Node Cumulative Next Batch Process Time: 7
> 3: Node Cumulative Process Time: 7
> 4: Node Next Batch Calls: 2
> 5: Node Blocks: 1
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Child 0:
> ProjectNode
> + Relational Node ID:3
> + Output Columns:file (clob)
> + Statistics:
> 0: Node Output Rows: 1
> 1: Node Next Batch Process Time: 0
> 2: Node Cumulative Next Batch Process Time: 2
> 3: Node Cumulative Process Time: 2
> 4: Node Next Batch Calls: 1
> 5: Node Blocks: 0
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Child 0:
> AccessNode
> + Relational Node ID:4
> + Output Columns:
> 0: file (clob)
> 1: filePath (string)
> + Statistics:
> 0: Node Output Rows: 1
> 1: Node Next Batch Process Time: 2
> 2: Node Cumulative Next Batch Process Time: 2
> 3: Node Cumulative Process Time: 2
> 4: Node Next Batch Calls: 1
> 5: Node Blocks: 0
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Query:EXEC MarketData.getTextFiles('*.txt')
> + Model Name:MarketData
> + Select Columns:MarketData.getTextFiles.file
> + Child 1:
> TextTableNode
> + Relational Node ID:5
> + Output Columns:
> 0: symbol (string)
> 1: price (bigdecimal)
> + Statistics:
> 0: Node Output Rows: 10
> 1: Node Next Batch Process Time: 3
> 2: Node Cumulative Next Batch Process Time: 3
> 3: Node Cumulative Process Time: 3
> 4: Node Next Batch Calls: 2
> 5: Node Blocks: 1
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Table Function:TEXTTABLE(f.file COLUMNS symbol string, price bigdecimal HEADER) AS SP
> + Join Strategy:NESTED TABLE JOIN
> + Join Type:CROSS JOIN
> + Join Criteria
> + Child 1:
> AccessNode
> + Relational Node ID:6
> + Output Columns:
> 0: SYMBOL (string)
> 1: ID (integer)
> 2: COMPANY_NAME (string)
> + Statistics:
> 0: Node Output Rows: 25
> 1: Node Next Batch Process Time: 1
> 2: Node Cumulative Next Batch Process Time: 1
> 3: Node Cumulative Process Time: 17
> 4: Node Next Batch Calls: 5
> 5: Node Blocks: 4
> + Cost Estimates:Estimated Node Cardinality: -1.0
> + Query:SELECT g_0.SYMBOL AS c_0, g_0.ID AS c_1, g_0.COMPANY_NAME AS c_2 FROM Accounts.PRODUCT AS g_0 ORDER BY c_0
> + Model Name:Accounts
> + Join Strategy:ENHANCED SORT JOIN RAN AS SORT MERGE (SORT/ALREADY_SORTED)
> + Join Type:INNER JOIN
> + Join Criteria:SP.symbol=A.SYMBOL
> + Select Columns:
> 0: A.ID AS product_id
> 1: SP.symbol
> 2: SP.price
> 3: A.COMPANY_NAME AS company_name
> + Data Bytes Sent:0
> + Planning Time:128
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (TEIID-3842) Teiid's query's explain not consistence with other Database
by Kylin Soong (JIRA)
Kylin Soong created TEIID-3842:
----------------------------------
Summary: Teiid's query's explain not consistence with other Database
Key: TEIID-3842
URL: https://issues.jboss.org/browse/TEIID-3842
Project: Teiid
Issue Type: Enhancement
Components: Query Engine
Affects Versions: 9.x
Reporter: Kylin Soong
Assignee: Kylin Soong
Fix For: 9.x
h2. The way to get execution plan is not consistence with others
For most of RDBMS(Oracle, Mysql), the execution plan get via SQL query
{code}
explain select ...
{code}
But in Teiid, we need use Teiid API, and need enable showplan in advance:
{code}
statement.execute("set showplan on");
ResultSet rs = statement.executeQuery("select ...");
TeiidStatement tstatement = statement.unwrap(TeiidStatement.class);
PlanNode queryPlan = tstatement.getPlanDescription();
System.out.println(queryPlan);
{code}
Cache Hint can be added as prefix, so I think we can enhance that show plan also as prefix, in order for consistence with others.
h2. The plan structure is too complex
[1] is the query plan of dynamicvdb-datafederation which is 2 datasources' federation, it long, complex, for the users/customers, it's not easy for then to understand. So can we enhance that simplify the output, like add a format option that can output as matrix/table.
[1] dynamicvdb-datafederation's 'select * from Stock' query plan
{code}
ProjectNode
+ Relational Node ID:0
+ Output Columns:
0: product_id (integer)
1: symbol (string)
2: price (bigdecimal)
3: company_name (string)
+ Statistics:
0: Node Output Rows: 9
1: Node Next Batch Process Time: 0
2: Node Cumulative Next Batch Process Time: 12
3: Node Cumulative Process Time: 21
4: Node Next Batch Calls: 3
5: Node Blocks: 2
+ Cost Estimates:Estimated Node Cardinality: -1.0
+ Child 0:
JoinNode
+ Relational Node ID:1
+ Output Columns:
0: ID (integer)
1: symbol (string)
2: price (bigdecimal)
3: COMPANY_NAME (string)
+ Statistics:
0: Node Output Rows: 9
1: Node Next Batch Process Time: 4
2: Node Cumulative Next Batch Process Time: 12
3: Node Cumulative Process Time: 21
4: Node Next Batch Calls: 3
5: Node Blocks: 2
+ Cost Estimates:Estimated Node Cardinality: -1.0
+ Child 0:
JoinNode
+ Relational Node ID:2
+ Output Columns:
0: symbol (string)
1: price (bigdecimal)
+ Statistics:
0: Node Output Rows: 10
1: Node Next Batch Process Time: 2
2: Node Cumulative Next Batch Process Time: 7
3: Node Cumulative Process Time: 7
4: Node Next Batch Calls: 2
5: Node Blocks: 1
+ Cost Estimates:Estimated Node Cardinality: -1.0
+ Child 0:
ProjectNode
+ Relational Node ID:3
+ Output Columns:file (clob)
+ Statistics:
0: Node Output Rows: 1
1: Node Next Batch Process Time: 0
2: Node Cumulative Next Batch Process Time: 2
3: Node Cumulative Process Time: 2
4: Node Next Batch Calls: 1
5: Node Blocks: 0
+ Cost Estimates:Estimated Node Cardinality: -1.0
+ Child 0:
AccessNode
+ Relational Node ID:4
+ Output Columns:
0: file (clob)
1: filePath (string)
+ Statistics:
0: Node Output Rows: 1
1: Node Next Batch Process Time: 2
2: Node Cumulative Next Batch Process Time: 2
3: Node Cumulative Process Time: 2
4: Node Next Batch Calls: 1
5: Node Blocks: 0
+ Cost Estimates:Estimated Node Cardinality: -1.0
+ Query:EXEC MarketData.getTextFiles('*.txt')
+ Model Name:MarketData
+ Select Columns:MarketData.getTextFiles.file
+ Child 1:
TextTableNode
+ Relational Node ID:5
+ Output Columns:
0: symbol (string)
1: price (bigdecimal)
+ Statistics:
0: Node Output Rows: 10
1: Node Next Batch Process Time: 3
2: Node Cumulative Next Batch Process Time: 3
3: Node Cumulative Process Time: 3
4: Node Next Batch Calls: 2
5: Node Blocks: 1
+ Cost Estimates:Estimated Node Cardinality: -1.0
+ Table Function:TEXTTABLE(f.file COLUMNS symbol string, price bigdecimal HEADER) AS SP
+ Join Strategy:NESTED TABLE JOIN
+ Join Type:CROSS JOIN
+ Join Criteria
+ Child 1:
AccessNode
+ Relational Node ID:6
+ Output Columns:
0: SYMBOL (string)
1: ID (integer)
2: COMPANY_NAME (string)
+ Statistics:
0: Node Output Rows: 25
1: Node Next Batch Process Time: 1
2: Node Cumulative Next Batch Process Time: 1
3: Node Cumulative Process Time: 17
4: Node Next Batch Calls: 5
5: Node Blocks: 4
+ Cost Estimates:Estimated Node Cardinality: -1.0
+ Query:SELECT g_0.SYMBOL AS c_0, g_0.ID AS c_1, g_0.COMPANY_NAME AS c_2 FROM Accounts.PRODUCT AS g_0 ORDER BY c_0
+ Model Name:Accounts
+ Join Strategy:ENHANCED SORT JOIN RAN AS SORT MERGE (SORT/ALREADY_SORTED)
+ Join Type:INNER JOIN
+ Join Criteria:SP.symbol=A.SYMBOL
+ Select Columns:
0: A.ID AS product_id
1: SP.symbol
2: SP.price
3: A.COMPANY_NAME AS company_name
+ Data Bytes Sent:0
+ Planning Time:128
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (TEIID-3829) olingo module junit test failed
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-3829?page=com.atlassian.jira.plugin... ]
Kylin Soong commented on TEIID-3829:
------------------------------------
I have verified add timezone fixed, but the change not commit to 8.13.
> olingo module junit test failed
> -------------------------------
>
> Key: TEIID-3829
> URL: https://issues.jboss.org/browse/TEIID-3829
> Project: Teiid
> Issue Type: Quality Risk
> Components: Build/Kits
> Affects Versions: 8.9
> Reporter: Kylin Soong
> Assignee: Steven Hawkins
> Fix For: 8.13, 8.12.3
>
>
> olingo module junit test failed:
> {code}
> Results :
> Failed tests:
> TestODataSQLBuilder.testEq:431->te:400->helpTest:227 expected:<...g0 WHERE g0.e1 = {t'[04]:20:02'} ORDER BY g0...> but was:<...g0 WHERE g0.e1 = {t'[16]:20:02'} ORDER BY g0...>
> TestODataSQLBuilder.testTimeMethods:552->te:400->helpTest:227 expected:<...YEAR({ts'2008-10-13 [04]:20:02.0'}) = 2008 O...> but was:<...YEAR({ts'2008-10-13 [16]:20:02.0'}) = 2008 O...>
> Tests run: 109, Failures: 2, Errors: 0, Skipped: 0
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (TEIID-3841) sap-nw-gateway translator wrongly encodes when a parameter includes a space
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3841?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3841:
---------------------------------------
I can reproduce this against 8.12.x, so I should have a fix shortly.
> sap-nw-gateway translator wrongly encodes when a parameter includes a space
> ---------------------------------------------------------------------------
>
> Key: TEIID-3841
> URL: https://issues.jboss.org/browse/TEIID-3841
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Reporter: Marc Shirley
> Assignee: Steven Hawkins
>
> Submitting a function through the sap-nw-gateway translator results in overzealous encoding of the URL when one of the parameters includes a space like "AA AB". The '?' character (along with the spaces in any parameters) in the expected URL [1] is encoded to '%3F' resulting in an error like [2] below.
> [1] https://sapes1.sapdevcenter.com/sap/opu/odata/IWFND/RMTSAMPLEFLIGHT/GetFl...'AA AB'&connectionid='0017'
> [2] org.teiid.runtime.client.TeiidClientException: java.lang.RuntimeException: Remote org.teiid.core.TeiidProcessingException: TEIID30504 flightdemo: TEIID17013 Wrong response from source with HTTP Response Code 404: Vendor Code "005056A509B11EE1B9A8FEC11C21D78E": With message "Resource not found for the segment 'GetFlightDetails%3Fairlineid='AA%20AB'&connectionid='0017''.": Detail Error null
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (TEIID-3725) In the JDG translators, enable named cache swapping so that materialization can be supported
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-3725?page=com.atlassian.jira.plugin... ]
Van Halbert edited comment on TEIID-3725 at 11/23/15 6:28 PM:
--------------------------------------------------------------
Looking at an example of dynamic vdb and materialization:
...
MATERIALIZED_TABLE 'Accounts.h2_stock_mat',
"teiid_rel:MATVIEW_TTL" 60000,
"teiid_rel:MATVIEW_BEFORE_LOAD_SCRIPT" 'execute accounts.native(''truncate table mat_stock_staging'');',
"teiid_rel:MATVIEW_AFTER_LOAD_SCRIPT" 'execute accounts.native(''ALTER TABLE h2_stock_mat RENAME TO h2_stock_mat_temp'');execute accounts.native(''ALTER TABLE mat_stock_staging RENAME TO h2_stock_mat'');execute accounts.native(''ALTER TABLE h2_stock_mat_temp RENAME TO mat_stock_staging'');',
"teiid_rel:ON_VDB_DROP_SCRIPT" 'DELETE FROM Accounts.status WHERE Name=''stockPricesMatView'' AND schemaname = ''StocksMatModel''',
"teiid_rel:MATERIALIZED_STAGE_TABLE" 'Accounts.mat_stock_staging',
"teiid_rel:ALLOW_MATVIEW_MANAGEMENT" 'true',
"teiid_rel:MATVIEW_STATUS_TABLE" 'status',
"teiid_rel:MATVIEW_SHARE_SCOPE" 'NONE',
"teiid_rel:MATVIEW_ONERROR_ACTION" 'THROW_EXCEPTION')
...
What about supporting native calls to be caught by the translator to swap the names? Or maybe a pushed down function call that the translator caught to swap the cache?
By using similar options related to using the above properties would keep it consistent, regardless type of data source used.
was (Author: van.halbert):
Looking at an example of dynamic vdb and materialization:
...
MATERIALIZED_TABLE 'Accounts.h2_stock_mat',
"teiid_rel:MATVIEW_TTL" 60000,
"teiid_rel:MATVIEW_BEFORE_LOAD_SCRIPT" 'execute accounts.native(''truncate table mat_stock_staging'');',
"teiid_rel:MATVIEW_AFTER_LOAD_SCRIPT" 'execute accounts.native(''ALTER TABLE h2_stock_mat RENAME TO h2_stock_mat_temp'');execute accounts.native(''ALTER TABLE mat_stock_staging RENAME TO h2_stock_mat'');execute accounts.native(''ALTER TABLE h2_stock_mat_temp RENAME TO mat_stock_staging'');',
"teiid_rel:ON_VDB_DROP_SCRIPT" 'DELETE FROM Accounts.status WHERE Name=''stockPricesMatView'' AND schemaname = ''StocksMatModel''',
"teiid_rel:MATERIALIZED_STAGE_TABLE" 'Accounts.mat_stock_staging',
"teiid_rel:ALLOW_MATVIEW_MANAGEMENT" 'true',
"teiid_rel:MATVIEW_STATUS_TABLE" 'status',
"teiid_rel:MATVIEW_SHARE_SCOPE" 'NONE',
"teiid_rel:MATVIEW_ONERROR_ACTION" 'THROW_EXCEPTION')
...
What about supporting native calls to be caught by the translator to swap the names? Or maybe a pushed down function call that the translator caught to swap the cache?
By using similar options that are used for relational sources would keep it consistent, regardless type of data source used.
> In the JDG translators, enable named cache swapping so that materialization can be supported
> --------------------------------------------------------------------------------------------
>
> Key: TEIID-3725
> URL: https://issues.jboss.org/browse/TEIID-3725
> Project: Teiid
> Issue Type: Feature Request
> Components: Misc. Connectors
> Affects Versions: 8.12
> Reporter: Van Halbert
> Assignee: Van Halbert
>
> The JDG translators, that in order to support materialization, will need to enable the named cache that's referenced by the connection, to be swapped. This is due to JDG doesn't currently support renaming a cache (i.e., like table rename in JDBC). And because of that, it limits how the cache can be refreshed (don't want to clear it before re-loading).
> Ideas are:
> 1. configure translator with the 2 cache names to use (a) initial cache to read from and (b) the staging cache to use
> perform materialize load
> call SYSADMIN.setProperty to trigger the swapping of the cache names
> 2 ???
> Note: because there's no persistence in Teiid so that any cache name changes will outlive a server restart, when a restart occurs, the translator will read from the cache identified as the initial cache to read from.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (TEIID-3725) In the JDG translators, enable named cache swapping so that materialization can be supported
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-3725?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-3725:
------------------------------------
Looking at an example of dynamic vdb and materialization:
...
MATERIALIZED_TABLE 'Accounts.h2_stock_mat',
"teiid_rel:MATVIEW_TTL" 60000,
"teiid_rel:MATVIEW_BEFORE_LOAD_SCRIPT" 'execute accounts.native(''truncate table mat_stock_staging'');',
"teiid_rel:MATVIEW_AFTER_LOAD_SCRIPT" 'execute accounts.native(''ALTER TABLE h2_stock_mat RENAME TO h2_stock_mat_temp'');execute accounts.native(''ALTER TABLE mat_stock_staging RENAME TO h2_stock_mat'');execute accounts.native(''ALTER TABLE h2_stock_mat_temp RENAME TO mat_stock_staging'');',
"teiid_rel:ON_VDB_DROP_SCRIPT" 'DELETE FROM Accounts.status WHERE Name=''stockPricesMatView'' AND schemaname = ''StocksMatModel''',
"teiid_rel:MATERIALIZED_STAGE_TABLE" 'Accounts.mat_stock_staging',
"teiid_rel:ALLOW_MATVIEW_MANAGEMENT" 'true',
"teiid_rel:MATVIEW_STATUS_TABLE" 'status',
"teiid_rel:MATVIEW_SHARE_SCOPE" 'NONE',
"teiid_rel:MATVIEW_ONERROR_ACTION" 'THROW_EXCEPTION')
...
What about supporting native calls to be caught by the translator to swap the names? Or maybe a pushed down function call that the translator caught to swap the cache?
By using similar options that are used for relational sources would keep it consistent, regardless type of data source used.
> In the JDG translators, enable named cache swapping so that materialization can be supported
> --------------------------------------------------------------------------------------------
>
> Key: TEIID-3725
> URL: https://issues.jboss.org/browse/TEIID-3725
> Project: Teiid
> Issue Type: Feature Request
> Components: Misc. Connectors
> Affects Versions: 8.12
> Reporter: Van Halbert
> Assignee: Van Halbert
>
> The JDG translators, that in order to support materialization, will need to enable the named cache that's referenced by the connection, to be swapped. This is due to JDG doesn't currently support renaming a cache (i.e., like table rename in JDBC). And because of that, it limits how the cache can be refreshed (don't want to clear it before re-loading).
> Ideas are:
> 1. configure translator with the 2 cache names to use (a) initial cache to read from and (b) the staging cache to use
> perform materialize load
> call SYSADMIN.setProperty to trigger the swapping of the cache names
> 2 ???
> Note: because there's no persistence in Teiid so that any cache name changes will outlive a server restart, when a restart occurs, the translator will read from the cache identified as the initial cache to read from.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (TEIID-3810) Updating teiid-tools archetypes
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-3810?page=com.atlassian.jira.plugin... ]
Van Halbert resolved TEIID-3810.
--------------------------------
Resolution: Done
The translator and connector archetypes have been released to nexus.
Translator:
********
* where:
********
-DarchetypeGroupId - is the group ID for the arche type to use to generate
-DarchetypeArtifactId - is the artifact ID for the arche type to use to generate
-DarchetypeVersion - is the version for the arche type to use to generate
-DgroupId - (user defined) group ID for the new translator project pom.xml
-DartifactId - (user defined) artifact ID for the new translator project pom.xml
-Dpackage - (user defined) the package structure where the java and resource files will be created
-Dversion - (user defined) the version that the new connector project pom.xml will be
-Dtranslator-type - (user defined) the translator type that's used by Teiid when mapping the physical source to the translator to use
-Dtranslator-name - (user defined) the translator name thats used for name the java class names
-Dteiid-version - [optional] the Teiid version the connector will depend upon, if not specified will default
example:
mvn archetype:generate -DarchethypeRepository=https://repository.jboss.org/nexus/content/repositories/releases/ \
-DarchetypeGroupId=org.jboss.teiid.arche-types \
-DarchetypeArtifactId=translator-archetype \
-DarchetypeVersion=8.12.0 \
-DgroupId=org.jboss.teiid.connectors \
-DartifactId=translator-myType \
-Dpackage=org.teiid.translator.myType \
-Dversion=0.0.1-SNAPSHOT \
-Dtranslator-type=mytype \
-Dtranslator-name=MyType \
-Dteiid-version=8.12.0.Final
Connector:
********
* where:
********
-DarchetypeGroupId - is the group ID for the arche type to use to generate
-DarchetypeArtifactId - is the artifact ID for the arche type to use to generate
-DarchetypeVersion - is the version for the arche type to use to generate
-DgroupId - (user defined) group ID for the new connector project pom.xml
-DartifactId - (user defined) artifact ID for the new connector project pom.xml
-Dpackage - (user defined) the package structure where the java and resource files will be created
-Dversion - (user defined) the version that the new connector project pom.xml will be
-Dconnector-type - (user defined) the type of the new connector project, used in defining the package name
-Dconnector-name - (user defined) the name of the new connector project, used as the prefix to creating the java class names
-Dvendor-name - name of the Vendor for the data source, updates the rar
-Dteiid-version - [optional] the Teiid version the connector will depend upon
example:
mvn archetype:generate -DarchetypeRepository=https://repository.jboss.org/nexus/content/repositories/releases/ \
-DarchetypeGroupId=org.jboss.teiid.arche-types \
-DarchetypeArtifactId=connector-archetype \
-DarchetypeVersion=8.12.0 \
-DgroupId=org.jboss.teiid.connectors \
-Dpackage=org.teiid.resource.adapter.mytype \
-DartifactId=connector-mytype \
-Dversion=0.0.1-SNAPSHOT \
-Dconnector-type=mytype \
-Dconnector-name=MyType \
-Dvendor-name=MyVendor \
-Dteiid-version=8.12.0.Final
> Updating teiid-tools archetypes
> --------------------------------
>
> Key: TEIID-3810
> URL: https://issues.jboss.org/browse/TEIID-3810
> Project: Teiid
> Issue Type: Task
> Components: Tools
> Affects Versions: 8.12.x
> Reporter: Van Halbert
> Assignee: Van Halbert
> Fix For: 8.12.x
>
>
> Updating teiid-tools archetypes to be based on Teiid 8.12.0.Final
> Adding in a docs section to be included with the jboss-as7 distribution.
> Adding a default ResourceAdapter for the connector.
> Adding an example ExecutionFactory unit test that provides a starting point.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (TEIID-3831) For results set caching there should scope metadata for source tables/procedures
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3831?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3831:
---------------------------------------
The approach here will be to look for a DETERMINISM relational property on the schema / model properties and on the non-temporary tables / procedures in the source queries (We will already assume session scoping for temporary tables). We'll also allow the cache directive scope to influence the determinism level. I'll see if it makes sense to add a another way to set the scope programtically - it seems like we'll need that for TEIID-3738
> For results set caching there should scope metadata for source tables/procedures
> --------------------------------------------------------------------------------
>
> Key: TEIID-3831
> URL: https://issues.jboss.org/browse/TEIID-3831
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.12.x
>
>
> Functions have optional metadata to convey their determinism, which affects the caching scope. However we don't have extension metadata or per execution metadata around source queries (there is a scope field on a cache directive, but that only applies to source level caching). We should provide a general mechanism so that users aren't required to manually override the result set cache scope.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months