December 2011 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-1857) Temp table becomes unusable by other threads

by Rick Wagner (Created) (JIRA)

Temp table becomes unusable by other threads -------------------------------------------- Key: TEIID-1857 URL: https://issues.jboss.org/browse/TEIID-1857 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 7.1 Reporter: Rick Wagner Assignee: Steven Hawkins Priority: Critical Fix For: 7.4.1, 7.6 If an update fails, the atomic rollback processing fails to properly unlock the write lock. Any other subsequent thread accessing the table would be locked out. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

2
1
0 / 0

[JBoss JIRA] (TEIID-3) Allow connectors to specify function capability for specific type signature

by Steven Hawkins (Updated) (JIRA)

[ https://issues.jboss.org/browse/TEIID-3?page=com.atlassian.jira.plugin.sy... ] Steven Hawkins updated TEIID-3: ------------------------------- Issue Type: Quality Risk (was: Bug) Fix Version/s: 8.0 (was: 9.x) Priority: Major (was: Optional) Affects Version/s: 6.0.0 (was: 9.x) Placing into 8.0. At the very least we'll add a specific execution factory method for converts (similar to DatabaseMetadata). > Allow connectors to specify function capability for specific type signature > --------------------------------------------------------------------------- > > Key: TEIID-3 > URL: https://issues.jboss.org/browse/TEIID-3 > Project: Teiid > Issue Type: Quality Risk > Components: Misc. Connectors > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Fix For: 8.0 > > > Defect Tracker #15144: Connectors should be able to specify pushdown capability for particular type signatures of a function. We have seen several cases where this would be helpful. This can probably be done without changing current Connector API by allowing the ConnectorCapabilities function method to return method signatures instead of just function names. For example, "mod(integer, integer)" instead of just "mod". Needs some further design still. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-7) Control of BigDecimal precision and scale

by Steven Hawkins (Resolved) (JIRA)

[ https://issues.jboss.org/browse/TEIID-7?page=com.atlassian.jira.plugin.sy... ] Steven Hawkins resolved TEIID-7. -------------------------------- Resolution: Partially Completed Problem 1/2 have already been addressed by other issues. Setting explicit precision and scale is a broader issue. Currently the type system is too simplistic to allow for additional facets. > Control of BigDecimal precision and scale > ----------------------------------------- > > Key: TEIID-7 > URL: https://issues.jboss.org/browse/TEIID-7 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 9.x > Reporter: Jerry Helbling > Priority: Minor > Fix For: 8.0 > > > Problem 1: The parser defaults to parsing literals that look like bigdecimal as doubles, which have no scale. > Workaround (which is on devcentral): You can avoid the above conversions by wrapping the values in a convert in the query (example: "convert('123.00', BigDecimal )"). > A better fix is update the parser to look for loss of scale information and to use the bigdecimal type instead. > Problem 2: default division behavior JBEDSP-305 > Problem 3: No explicit control via the parser > It would be good to provide explicit precision and scale via "convert(xxx, BigDecimal(10, 2))" - side note bigdecimal is a bad name for this type. it should really just be decimal > Reference: This is related to Issue Tracker Issue 175485. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] Created: (TEIID-1679) The parser should parse identifier parts separately

by Steven Hawkins (JIRA)

The parser should parse identifier parts separately --------------------------------------------------- Key: TEIID-1679 URL: https://issues.jboss.org/browse/TEIID-1679 Project: Teiid Issue Type: Quality Risk Components: Query Engine Affects Versions: 8.0 Reporter: Steven Hawkins Assignee: Steven Hawkins Priority: Minor Fix For: 8.0 The parser currently uses tokens to represent identifiers and all in group. Technically . should be a token. This would be a breaking change - something like order.*, would be forced to be entered as "order".* -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

3
2
0 / 0

[JBoss JIRA] (TEIID-1855) Exact numeric issues

by Van Halbert (Created) (JIRA)

Exact numeric issues -------------------- Key: TEIID-1855 URL: https://issues.jboss.org/browse/TEIID-1855 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 6.0.0 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 8.0 Teiid diverges from the SQL spec by parsing numerical expressions of the form <integral value>.<integral value> as doubles rather than as an exact numeric type (which for us would be BigDecimal). I believe this was originally done to match Java parsing semantics and potentially to avoid performance overhead of using BigBecimal. However this can lead to a loss of precision that is not expected by ANSI SQL. inexact numeric values entered in scientific notation would not be affected by this change. They would still be parsed as doubles. The SQL spec also requires that the result of AVG on an exact type be returned as an exact type (although precision and scale are implementation dependent). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues December 2011