[JBoss JIRA] (TEIID-2396) count of column returns null instead of 0 over join
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-2396:
-------------------------------------
Summary: count of column returns null instead of 0 over join
Key: TEIID-2396
URL: https://issues.jboss.org/browse/TEIID-2396
Project: Teiid
Issue Type: Bug
Components: Query Engine
Affects Versions: 7.0
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Priority: Critical
Fix For: 8.3
The aggregate pushing logic will decompose a count as a sum of count, which can be null if no rows are returned by the join.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (TEIID-2395) ReusableExecutions are created everytime after DataNotAvailable is thrown
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2395?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2395.
-----------------------------------
Resolution: Rejected
The patch must be applied incorrectly. When I run the test case I see:
TimerExecution.TimerExecution()
TimerExecution.execute() RESULT
TimerExecution.close()
On Row 2013-02-15 08:12:37.3
TimerExecution.reset()
TimerExecution.execute() WAIT
TimerExecution.execute() RESULT
TimerExecution.close()
On Row 2013-02-15 08:12:37.603
TimerExecution.reset()
TimerExecution.execute() WAIT
TimerExecution.execute() RESULT
TimerExecution.close()
On Row 2013-02-15 08:12:37.705
TimerExecution.reset()
TimerExecution.execute() WAIT
TimerExecution.execute() RESULT
TimerExecution.close()
...
In general with something like this you'll need to reproduce the issue against the current version (even if it's a prerelease) rather than against a patched version before logging an issue.
> ReusableExecutions are created everytime after DataNotAvailable is thrown
> -------------------------------------------------------------------------
>
> Key: TEIID-2395
> URL: https://issues.jboss.org/browse/TEIID-2395
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.1
> Reporter: Sanjeev Gour
> Assignee: Steven Hawkins
> Attachments: Testcase.zip
>
>
> We did a test with a simple ReusableExecution and found that new executions are being created every time after DataNotAvailableExecption is thrown. Here is the life cycle after the recent patch for issue https://issues.jboss.org/browse/TEIID-2322 was applied-
> TimerExecution.TimerExecution()
> TimerExecution.execute() RESULT
> TimerExecution.close()
> On Row 2013-02-15 17:41:03.421
> TimerExecution.reset()
> TimerExecution.execute() WAIT
> TimerExecution.TimerExecution()
> TimerExecution.execute() RESULT
> TimerExecution.close()
> On Row 2013-02-15 17:41:03.556
> TimerExecution.reset()
> TimerExecution.execute() WAIT
> TimerExecution.TimerExecution()
> TimerExecution.execute() RESULT
> TimerExecution.close()
> On Row 2013-02-15 17:41:03.661
> TimerExecution.reset()
> TimerExecution.execute() WAIT
> TimerExecution.TimerExecution()
> TimerExecution.execute() RESULT
> TimerExecution.close()
> On Row 2013-02-15 17:41:03.766
> TimerExecution.reset()
> TimerExecution.execute() WAIT
> The same test when run against the jar before the fix was applied is this-
> TimerExecution.TimerExecution()
> TimerExecution.execute() RESULT
> TimerExecution.close()
> On Row 2013-02-15 17:49:01.998
> TimerExecution.reset()
> TimerExecution.execute() WAIT
> TimerExecution.reset()
> TimerExecution.execute() RESULT
> TimerExecution.close()
> On Row 2013-02-15 17:49:02.123
> TimerExecution.reset()
> TimerExecution.execute() WAIT
> TimerExecution.reset()
> TimerExecution.execute() RESULT
> TimerExecution.close()
> On Row 2013-02-15 17:49:02.228
> TimerExecution.reset()
> TimerExecution.execute() WAIT
> TimerExecution.reset()
> TimerExecution.execute() RESULT
> TimerExecution.close()
> On Row 2013-02-15 17:49:02.333
> TimerExecution.reset()
> TimerExecution.execute() WAIT
> TimerExecution.reset()
> TimerExecution.execute() RESULT
> TimerExecution.close()
> On Row 2013-02-15 17:49:02.438
> TimerExecution.reset()
> TimerExecution.execute() WAIT
> TimerExecution.reset()
> The testcase is attached.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (TEIID-2395) ReusableExecutions are created everytime after DataNotAvailable is thrown
by Sanjeev Gour (JIRA)
[ https://issues.jboss.org/browse/TEIID-2395?page=com.atlassian.jira.plugin... ]
Sanjeev Gour updated TEIID-2395:
--------------------------------
Attachment: Testcase.zip
Test case to reproduce the issue.
> ReusableExecutions are created everytime after DataNotAvailable is thrown
> -------------------------------------------------------------------------
>
> Key: TEIID-2395
> URL: https://issues.jboss.org/browse/TEIID-2395
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.1
> Reporter: Sanjeev Gour
> Assignee: Steven Hawkins
> Attachments: Testcase.zip
>
>
> We did a test with a simple ReusableExecution and found that new executions are being created every time after DataNotAvailableExecption is thrown. Here is the life cycle after the recent patch for issue https://issues.jboss.org/browse/TEIID-2322 was applied-
> TimerExecution.TimerExecution()
> TimerExecution.execute() RESULT
> TimerExecution.close()
> On Row 2013-02-15 17:41:03.421
> TimerExecution.reset()
> TimerExecution.execute() WAIT
> TimerExecution.TimerExecution()
> TimerExecution.execute() RESULT
> TimerExecution.close()
> On Row 2013-02-15 17:41:03.556
> TimerExecution.reset()
> TimerExecution.execute() WAIT
> TimerExecution.TimerExecution()
> TimerExecution.execute() RESULT
> TimerExecution.close()
> On Row 2013-02-15 17:41:03.661
> TimerExecution.reset()
> TimerExecution.execute() WAIT
> TimerExecution.TimerExecution()
> TimerExecution.execute() RESULT
> TimerExecution.close()
> On Row 2013-02-15 17:41:03.766
> TimerExecution.reset()
> TimerExecution.execute() WAIT
> The same test when run against the jar before the fix was applied is this-
> TimerExecution.TimerExecution()
> TimerExecution.execute() RESULT
> TimerExecution.close()
> On Row 2013-02-15 17:49:01.998
> TimerExecution.reset()
> TimerExecution.execute() WAIT
> TimerExecution.reset()
> TimerExecution.execute() RESULT
> TimerExecution.close()
> On Row 2013-02-15 17:49:02.123
> TimerExecution.reset()
> TimerExecution.execute() WAIT
> TimerExecution.reset()
> TimerExecution.execute() RESULT
> TimerExecution.close()
> On Row 2013-02-15 17:49:02.228
> TimerExecution.reset()
> TimerExecution.execute() WAIT
> TimerExecution.reset()
> TimerExecution.execute() RESULT
> TimerExecution.close()
> On Row 2013-02-15 17:49:02.333
> TimerExecution.reset()
> TimerExecution.execute() WAIT
> TimerExecution.reset()
> TimerExecution.execute() RESULT
> TimerExecution.close()
> On Row 2013-02-15 17:49:02.438
> TimerExecution.reset()
> TimerExecution.execute() WAIT
> TimerExecution.reset()
> The testcase is attached.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (TEIID-2395) ReusableExecutions are created everytime after DataNotAvailable is thrown
by Sanjeev Gour (JIRA)
Sanjeev Gour created TEIID-2395:
-----------------------------------
Summary: ReusableExecutions are created everytime after DataNotAvailable is thrown
Key: TEIID-2395
URL: https://issues.jboss.org/browse/TEIID-2395
Project: Teiid
Issue Type: Bug
Affects Versions: 8.1
Reporter: Sanjeev Gour
Assignee: Steven Hawkins
We did a test with a simple ReusableExecution and found that new executions are being created every time after DataNotAvailableExecption is thrown. Here is the life cycle after the recent patch for issue https://issues.jboss.org/browse/TEIID-2322 was applied-
TimerExecution.TimerExecution()
TimerExecution.execute() RESULT
TimerExecution.close()
On Row 2013-02-15 17:41:03.421
TimerExecution.reset()
TimerExecution.execute() WAIT
TimerExecution.TimerExecution()
TimerExecution.execute() RESULT
TimerExecution.close()
On Row 2013-02-15 17:41:03.556
TimerExecution.reset()
TimerExecution.execute() WAIT
TimerExecution.TimerExecution()
TimerExecution.execute() RESULT
TimerExecution.close()
On Row 2013-02-15 17:41:03.661
TimerExecution.reset()
TimerExecution.execute() WAIT
TimerExecution.TimerExecution()
TimerExecution.execute() RESULT
TimerExecution.close()
On Row 2013-02-15 17:41:03.766
TimerExecution.reset()
TimerExecution.execute() WAIT
The same test when run against the jar before the fix was applied is this-
TimerExecution.TimerExecution()
TimerExecution.execute() RESULT
TimerExecution.close()
On Row 2013-02-15 17:49:01.998
TimerExecution.reset()
TimerExecution.execute() WAIT
TimerExecution.reset()
TimerExecution.execute() RESULT
TimerExecution.close()
On Row 2013-02-15 17:49:02.123
TimerExecution.reset()
TimerExecution.execute() WAIT
TimerExecution.reset()
TimerExecution.execute() RESULT
TimerExecution.close()
On Row 2013-02-15 17:49:02.228
TimerExecution.reset()
TimerExecution.execute() WAIT
TimerExecution.reset()
TimerExecution.execute() RESULT
TimerExecution.close()
On Row 2013-02-15 17:49:02.333
TimerExecution.reset()
TimerExecution.execute() WAIT
TimerExecution.reset()
TimerExecution.execute() RESULT
TimerExecution.close()
On Row 2013-02-15 17:49:02.438
TimerExecution.reset()
TimerExecution.execute() WAIT
TimerExecution.reset()
The testcase is attached.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (TEIID-2372) Providing functionality to set source table cardinality when metadata loaded
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2372?page=com.atlassian.jira.plugin... ]
Steven Hawkins edited comment on TEIID-2372 at 2/14/13 3:38 PM:
----------------------------------------------------------------
Implemented the last suggestion.
{code}
ALTER FOREIGN TABLE {name) OPTIONS ( (ADD|SET|DROP) {prop-name} [{prop-value}] ... ) | ALTER COLUMN {name} OPTIONS ( (ADD|SET|DROP) {prop-name} [{prop-value}] ... )
{code}
The above also supports VIEWS and PROCEDURES. For example, if you want to add CARDINALITY to a table that you imported from a source database, you can do following.
{code:lang=XML}
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<vdb name="northwind" version="1">
<model name="nw">
<property name="importer.importKeys" value="true"/>
<property name="importer.importProcedures" value="true"/>
<source name="northwind-connector" translator-name="mysql" connection-jndi-name="java:/nw-ds"/>
<metadata type = "NATIVE,DDL"><![CDATA[
ALTER FOREIGN TABLE customers OPTIONS (ADD CARDINALITY 10000);
ALTER FOREIGN TABLE customers ALTER COLUMN CompanyName OPTIONS(ADD FOO 'BAR');
]]>
</metadata>
</model>
</vdb>
{code}
was (Author: rareddy):
Implemented the last suggestion.
{code}
ALTER FOREIGN TABLE {name) [(ADD|SET|DROP) {prop-name} {prop-value}]
[(,ALTER COLUMN {name} (ADD|SET|DROP) {prop-name} {prop-value})*]
{code}
The above also supports VIEWS and PROCEDURES. For example, if you want to add CARDINALITY to a table that you imported from a source database, you can do following.
{code:lang=XML}
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<vdb name="northwind" version="1">
<model name="nw">
<property name="importer.importKeys" value="true"/>
<property name="importer.importProcedures" value="true"/>
<source name="northwind-connector" translator-name="mysql" connection-jndi-name="java:/nw-ds"/>
<metadata type = "NATIVE,DDL"><![CDATA[
ALTER FOREIGN TABLE northwind.customers ADD CARDINALITY 10000,
ALTER COLUMN CompanyName ADD FOO 'BAR';
]]>
</metadata>
</model>
</vdb>
{code}
> Providing functionality to set source table cardinality when metadata loaded
> ----------------------------------------------------------------------------
>
> Key: TEIID-2372
> URL: https://issues.jboss.org/browse/TEIID-2372
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine
> Affects Versions: 8.2
> Reporter: Jack Ma
> Assignee: Ramesh Reddy
> Labels: CR1
> Fix For: 8.3
>
>
> Want to have a easy way to set the source table cardinality when source model metadata loaded
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (TEIID-2372) Providing functionality to set source table cardinality when metadata loaded
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2372?page=com.atlassian.jira.plugin... ]
Ramesh Reddy resolved TEIID-2372.
---------------------------------
Labels: CR1 (was: )
Resolution: Done
Implemented the last suggestion.
{code}
ALTER FOREIGN TABLE {name) [(ADD|SET|DROP) {prop-name} {prop-value}]
[(,ALTER COLUMN {name} (ADD|SET|DROP) {prop-name} {prop-value})*]
{code}
The above also supports VIEWS and PROCEDURES. For example, if you want to add CARDINALITY to a table that you imported from a source database, you can do following.
{code:lang=XML}
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<vdb name="northwind" version="1">
<model name="nw">
<property name="importer.importKeys" value="true"/>
<property name="importer.importProcedures" value="true"/>
<source name="northwind-connector" translator-name="mysql" connection-jndi-name="java:/nw-ds"/>
<metadata type = "NATIVE,DDL"><![CDATA[
ALTER FOREIGN TABLE northwind.customers ADD CARDINALITY 10000,
ALTER COLUMN CompanyName ADD FOO 'BAR';
]]>
</metadata>
</model>
</vdb>
{code}
> Providing functionality to set source table cardinality when metadata loaded
> ----------------------------------------------------------------------------
>
> Key: TEIID-2372
> URL: https://issues.jboss.org/browse/TEIID-2372
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine
> Affects Versions: 8.2
> Reporter: Jack Ma
> Assignee: Ramesh Reddy
> Labels: CR1
> Fix For: 8.3
>
>
> Want to have a easy way to set the source table cardinality when source model metadata loaded
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (TEIID-2394) Allow local connections to use thread bound transactions
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2394?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2394.
-----------------------------------
Resolution: Done
Promoted the EmbeddedServer thread bound transaction handling to the main TransactionServerImpl. Also added a check when starting a local transaction to prevent creating a nested transaction that is not currently handled correctly. This means that the disableLocalTxn property may still be needed if the client app is starting a local transaction.
This approach works fine as long as the application code does not do something odd, such as switching between active transactions in between calls to Teiid.
At some point we'll also want to look into properly supporting subtransactions - both for client calls and internally for better block transaction semantics.
> Allow local connections to use thread bound transactions
> --------------------------------------------------------
>
> Key: TEIID-2394
> URL: https://issues.jboss.org/browse/TEIID-2394
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Affects Versions: 7.0
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Minor
> Fix For: 8.3
>
>
> To facilitate usage of non-pooled local connections, it would be useful for the engine to automatically use the thread bound transaction for queries.
> An approximate workaround in local mode is to set the userSourceQueryConcurrency to 1 and use the disableLocalTxn property if needed to prevent calling code from starting a local transaction. The downside of this approach is that non-transactional work will be performed serially and Teiid temporary tables will not be transactionally aware.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (TEIID-2394) Allow local connections to use thread bound transactions
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-2394:
-------------------------------------
Summary: Allow local connections to use thread bound transactions
Key: TEIID-2394
URL: https://issues.jboss.org/browse/TEIID-2394
Project: Teiid
Issue Type: Enhancement
Components: Query Engine
Affects Versions: 7.0
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Priority: Minor
Fix For: 8.3
To facilitate usage of non-pooled local connections, it would be useful for the engine to automatically use the thread bound transaction for queries.
An approximate workaround in local mode is to set the userSourceQueryConcurrency to 1 and use the disableLocalTxn property if needed to prevent calling code from starting a local transaction. The downside of this approach is that non-transactional work will be performed serially and Teiid temporary tables will not be transactionally aware.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months