[JBoss JIRA] (TEIID-5153) RAND function gives same results in view
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5153?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-5153:
----------------------------------
Fix Version/s: 9.3.6
(was: 9.3.5)
> RAND function gives same results in view
> ----------------------------------------
>
> Key: TEIID-5153
> URL: https://issues.jboss.org/browse/TEIID-5153
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 9.3.4
> Environment: teiid-9.3.4 on WildFly Full 10.0.0.Final (WildFly Core 2.0.10.Final)
> Reporter: dalex dalex
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 10.1, 10.0.1, 9.3.6
>
>
> When using patched PostgreSQLExecutionFactory class to push down RAND function it starts to give the same values in a view. I wanted to push down RAND function in PostgreSQL for a while and noticed the bug related to identical values when using RAND function through a select in a view.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (TEIID-5153) RAND function gives same results in view
by dalex dalex (JIRA)
[ https://issues.jboss.org/browse/TEIID-5153?page=com.atlassian.jira.plugin... ]
dalex dalex commented on TEIID-5153:
------------------------------------
Ok [~shawkins], I will wait for your fix, thx!
> RAND function gives same results in view
> ----------------------------------------
>
> Key: TEIID-5153
> URL: https://issues.jboss.org/browse/TEIID-5153
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 9.3.4
> Environment: teiid-9.3.4 on WildFly Full 10.0.0.Final (WildFly Core 2.0.10.Final)
> Reporter: dalex dalex
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 9.3.5, 10.1, 10.0.1
>
>
> When using patched PostgreSQLExecutionFactory class to push down RAND function it starts to give the same values in a view. I wanted to push down RAND function in PostgreSQL for a while and noticed the bug related to identical values when using RAND function through a select in a view.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (TEIID-5153) RAND function gives same results in view
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5153?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5153:
---------------------------------------
Yes that introduced an issue. That code was very similar to what is used when removing a view layer, but in this case the source node is retained and needs to have the output symbols set. I'll check that fix in under this issue.
> RAND function gives same results in view
> ----------------------------------------
>
> Key: TEIID-5153
> URL: https://issues.jboss.org/browse/TEIID-5153
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 9.3.4
> Environment: teiid-9.3.4 on WildFly Full 10.0.0.Final (WildFly Core 2.0.10.Final)
> Reporter: dalex dalex
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 9.3.5, 10.1, 10.0.1
>
>
> When using patched PostgreSQLExecutionFactory class to push down RAND function it starts to give the same values in a view. I wanted to push down RAND function in PostgreSQL for a while and noticed the bug related to identical values when using RAND function through a select in a view.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (TEIID-5153) RAND function gives same results in view
by dalex dalex (JIRA)
[ https://issues.jboss.org/browse/TEIID-5153?page=com.atlassian.jira.plugin... ]
dalex dalex edited comment on TEIID-5153 at 11/30/17 11:28 AM:
---------------------------------------------------------------
Hi [~shawkins] it seems that I found a potential problem related to the new removal algorithm introduced by you
in the RuleCollapseSource.removeUnnecessaryInlineView method. If I set in debug mode RequestMessage.rowLimit field as 0 then
Teiid won't add a LIMIT clause in the end of original query (Request.generatePlan method, a check on requestMsg.getRowLimit() > 0 expression) and
we get the same error which was described in TEIID-3846 issue. Could you please check in additional?
To explain more precisely what is happening when we set rowLimit to 0: Teiid won't add TupleLimit node with particular limit value over all nodes and the RuleCollapseSource.removeUnnecessaryInlineView will remove some select symbols from a project node.
was (Author: dalex005):
Hi [~shawkins] it seems that I found a potential problem related to the new removal algorithm introduced by you
in the RuleCollapseSource.removeUnnecessaryInlineView method. If I set in debug mode RequestMessage.rowLimit field as 0 then
Teiid won't add a LIMIT clause in the end of original query (Request.generatePlan method, a check on requestMsg.getRowLimit() > 0 expression) and
we get the same error which was described in TEIID-3846 issue. Could you please check in additional?
> RAND function gives same results in view
> ----------------------------------------
>
> Key: TEIID-5153
> URL: https://issues.jboss.org/browse/TEIID-5153
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 9.3.4
> Environment: teiid-9.3.4 on WildFly Full 10.0.0.Final (WildFly Core 2.0.10.Final)
> Reporter: dalex dalex
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 9.3.5, 10.1, 10.0.1
>
>
> When using patched PostgreSQLExecutionFactory class to push down RAND function it starts to give the same values in a view. I wanted to push down RAND function in PostgreSQL for a while and noticed the bug related to identical values when using RAND function through a select in a view.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (TEIID-5153) RAND function gives same results in view
by dalex dalex (JIRA)
[ https://issues.jboss.org/browse/TEIID-5153?page=com.atlassian.jira.plugin... ]
dalex dalex commented on TEIID-5153:
------------------------------------
Hi [~shawkins] it seems that I found a potential problem related to the new removal algorithm introduced by you
in the RuleCollapseSource.removeUnnecessaryInlineView method. If I set in debug mode RequestMessage.rowLimit field as 0 then
Teiid won't add a LIMIT clause in the end of original query (Request.generatePlan method, a check on requestMsg.getRowLimit() > 0 expression) and
we get the same error which was described in TEIID-3846 issue. Could you please check in additional?
> RAND function gives same results in view
> ----------------------------------------
>
> Key: TEIID-5153
> URL: https://issues.jboss.org/browse/TEIID-5153
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 9.3.4
> Environment: teiid-9.3.4 on WildFly Full 10.0.0.Final (WildFly Core 2.0.10.Final)
> Reporter: dalex dalex
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 9.3.5, 10.1, 10.0.1
>
>
> When using patched PostgreSQLExecutionFactory class to push down RAND function it starts to give the same values in a view. I wanted to push down RAND function in PostgreSQL for a while and noticed the bug related to identical values when using RAND function through a select in a view.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (TEIID-5106) Tables names are case sensitive in Postgres/Oracle/MSSQL but not in Teiid.
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5106?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-5106.
-----------------------------------
Fix Version/s: 10.1
10.0.1
Resolution: Done
Thanks for spotting that it was of course unintended. So this will work for up to 1 duplicate table in 10.0 and will be corrected in 10.1 / 10.0.1
> Tables names are case sensitive in Postgres/Oracle/MSSQL but not in Teiid.
> --------------------------------------------------------------------------
>
> Key: TEIID-5106
> URL: https://issues.jboss.org/browse/TEIID-5106
> Project: Teiid
> Issue Type: Quality Risk
> Components: JDBC Connector
> Reporter: sameer P
> Assignee: Steven Hawkins
> Fix For: 10.1, 10.0.1, 10.0
>
>
> In Postgres/Oracle/MS , I can create two tables with the same name (but different cases): test12 and Test12 (by quoting it in create script) , but, Teiid complains saying duplicate table name and fails with the below error:
> {code:java}
> 16:53:11,161 WARN [org.teiid.RUNTIME] (Worker0_async-teiid-threads0) TEIID50036 VDB test.1 model "dsms" metadata failed to load. Reason:TEIID60013 Duplicate Table public.test12: org.teiid.metadata.DuplicateRecordException: TEIID60013 Duplicate Table public.test12
> at org.teiid.metadata.Schema.addTable(Schema.java:51)
> at org.teiid.metadata.MetadataFactory.addTable(MetadataFactory.java:179)
> at org.teiid.translator.jdbc.JDBCMetdataProcessor.addTable(JDBCMetdataProcessor.java:368)
> at org.teiid.translator.jdbc.JDBCMetdataProcessor.addTable(JDBCMetdataProcessor.java:351)
> at org.teiid.translator.jdbc.JDBCMetdataProcessor.getTables(JDBCMetdataProcessor.java:324)
> at org.teiid.translator.jdbc.JDBCMetdataProcessor.getConnectorMetadata(JDBCMetdataProcessor.java:166)
> at org.teiid.translator.jdbc.JDBCExecutionFactory.getMetadata(JDBCExecutionFactory.java:306)
> at org.teiid.translator.jdbc.JDBCExecutionFactory.getMetadata(JDBCExecutionFactory.java:69)
> at org.teiid.query.metadata.NativeMetadataRepository.getMetadata(NativeMetadataRepository.java:96)
> at org.teiid.query.metadata.NativeMetadataRepository.loadMetadata(NativeMetadataRepository.java:62)
> at org.teiid.query.metadata.ChainingMetadataRepository.loadMetadata(ChainingMetadataRepository.java:55)
> at org.teiid.jboss.VDBService$6.run(VDBService.java:341)
> at org.teiid.jboss.VDBService$7.run(VDBService.java:392)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:284)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (TEIID-5106) Tables names are case sensitive in Postgres/Oracle/MSSQL but not in Teiid.
by sameer P (JIRA)
[ https://issues.jboss.org/browse/TEIID-5106?page=com.atlassian.jira.plugin... ]
sameer P reopened TEIID-5106:
-----------------------------
[~shawkins], looks like the fix fails when there are more than two tables with same name. As it only applies the first prefix (_1) to all.
> Tables names are case sensitive in Postgres/Oracle/MSSQL but not in Teiid.
> --------------------------------------------------------------------------
>
> Key: TEIID-5106
> URL: https://issues.jboss.org/browse/TEIID-5106
> Project: Teiid
> Issue Type: Quality Risk
> Components: JDBC Connector
> Reporter: sameer P
> Assignee: Steven Hawkins
> Fix For: 10.0
>
>
> In Postgres/Oracle/MS , I can create two tables with the same name (but different cases): test12 and Test12 (by quoting it in create script) , but, Teiid complains saying duplicate table name and fails with the below error:
> {code:java}
> 16:53:11,161 WARN [org.teiid.RUNTIME] (Worker0_async-teiid-threads0) TEIID50036 VDB test.1 model "dsms" metadata failed to load. Reason:TEIID60013 Duplicate Table public.test12: org.teiid.metadata.DuplicateRecordException: TEIID60013 Duplicate Table public.test12
> at org.teiid.metadata.Schema.addTable(Schema.java:51)
> at org.teiid.metadata.MetadataFactory.addTable(MetadataFactory.java:179)
> at org.teiid.translator.jdbc.JDBCMetdataProcessor.addTable(JDBCMetdataProcessor.java:368)
> at org.teiid.translator.jdbc.JDBCMetdataProcessor.addTable(JDBCMetdataProcessor.java:351)
> at org.teiid.translator.jdbc.JDBCMetdataProcessor.getTables(JDBCMetdataProcessor.java:324)
> at org.teiid.translator.jdbc.JDBCMetdataProcessor.getConnectorMetadata(JDBCMetdataProcessor.java:166)
> at org.teiid.translator.jdbc.JDBCExecutionFactory.getMetadata(JDBCExecutionFactory.java:306)
> at org.teiid.translator.jdbc.JDBCExecutionFactory.getMetadata(JDBCExecutionFactory.java:69)
> at org.teiid.query.metadata.NativeMetadataRepository.getMetadata(NativeMetadataRepository.java:96)
> at org.teiid.query.metadata.NativeMetadataRepository.loadMetadata(NativeMetadataRepository.java:62)
> at org.teiid.query.metadata.ChainingMetadataRepository.loadMetadata(ChainingMetadataRepository.java:55)
> at org.teiid.jboss.VDBService$6.run(VDBService.java:341)
> at org.teiid.jboss.VDBService$7.run(VDBService.java:392)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:284)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (TEIID-5007) Changes to reduce Teiid in the cloud footprint
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5007?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5007:
---------------------------------------
Followed up on HA on TEIID-5131. As it isn't really germane to the footprint issue, the focus here will switch back to anything we should be doing with ephemeral disk usage. From https://github.com/jboss-openshift/openshift-examples/blob/master/hellowo... there is an openshift/logstash logging solution that should be used instead of disk - but is there anything specific that we'd want to do for audit/command logs
> Changes to reduce Teiid in the cloud footprint
> ----------------------------------------------
>
> Key: TEIID-5007
> URL: https://issues.jboss.org/browse/TEIID-5007
> Project: Teiid
> Issue Type: Quality Risk
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 10.1
>
>
> A Teiid instance even as swarm or springboot needs additional considerations to minimize the runtime footprint. This includes:
> * container aware auto-sizing. Detection of the number of cpus and available memory need refined - there are experimental settings being considered for containerized vms to better report these values and there is logic in WildFly and other projects that attempts better auto-detection. We also need to utilize the memory buffer space more and probably as off-heap space (and ideally direct operations on the serialized data)
> * Subsystems required include JTA, webserver, security, which could be satisfied by slimmer alternative versions - especially if we make new assumptions, such as not utilizing xa transactions.
> * Engine dependencies could be application specific - removing xml/xsl support, geometry support, etc.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (TEIID-5131) Create ansible playbooks for the ansible service broker
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5131?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5131:
---------------------------------------
We have a couple of options for routes / security:
1. stick with the current approach of creating a user account for all service access, and expose a route by default for odata access.
2. provide a route that is secured with the oauth proxy side car - https://github.com/openshift/oauth-proxy - which I need to understand a little more how to pass the basic auth credentials as likely still want to have the generated user account.
3. provide os sso integration - however most other examples demonstrate creating an sso instance (sso+eap) rather than reusing internal os sso
Since we aren't yet dealing with data roles all are valid. However once data roles come into the picture we need also authenticate the incoming user into Teiid, not just to a proxy.
> Create ansible playbooks for the ansible service broker
> -------------------------------------------------------
>
> Key: TEIID-5131
> URL: https://issues.jboss.org/browse/TEIID-5131
> Project: Teiid
> Issue Type: Enhancement
> Components: Build/Kits
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 10.1
>
>
> For some of the most common usage patterns, we should create playbooks that contribute service brokers via the ansible service broker. This could be:
> salesforce as db
> couchbase as db/odata
> mongodb as db/odata
> other openshift databases as odata
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months