[JBoss JIRA] (TEIID-2622) Data/plan modification check is not granular enough
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2622?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2622.
-----------------------------------
Resolution: Done
changed to simply invalid when the modification time matches the entry time. other methods such as using a version number are not as cluster friendly (although we're assuming low clock skew for the timestamping to be cluster friendly). It may still be beneficial to use versioning at some point.
This may introduce situations especially on systems with poor time resolution of being too cautious about using cache entries - but sense we typical caching either plan is typically used for operations lasting longer than typical time resolutions this seems fine for now.
> Data/plan modification check is not granular enough
> ---------------------------------------------------
>
> Key: TEIID-2622
> URL: https://issues.jboss.org/browse/TEIID-2622
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.4.1, 8.5
>
>
> The use of milliseconds will cause some situations (such as in the TestAsynch alter test) where modifications do not seem to be honored.
--
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
12 years, 7 months
[JBoss JIRA] (TEIID-2422) Offer support for a timestampdiff based upon calendar fields
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2422?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2422:
---------------------------------------
This change set was missed for 8.4, but was added for 8.4.1/8.5.
> Offer support for a timestampdiff based upon calendar fields
> ------------------------------------------------------------
>
> Key: TEIID-2422
> URL: https://issues.jboss.org/browse/TEIID-2422
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.3
>
>
> There is little consistency among timestampdiff implementations, however ours seems to be based off of the db2 (http://pic.dhe.ibm.com/infocenter/dzichelp/v2r2/topic/com.ibm.db2z9.doc.s...) timestampdiff in terms of intervals - but does not make all the same assumptions in the calculation of the answer.
> It would be good to provide an option so that our timestampdiff or another system function would calculate differences based upon calendar fields (following the behavior of SQL Server) rather than just based upon the interval - for example the months between 2012-02-20 and 2012-03-01 would report 1 rather than the current answer of 0).
> There is also a general issue with the consistency of the results with the pushdowned versions of timestampdiff as vendor support varies.
--
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
12 years, 7 months
[JBoss JIRA] (TEIID-2621) improve texttable error messages
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2621?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2621.
-----------------------------------
Resolution: Done
There was very little here that could be done easily. The improvements made were to infer the byte position of the failing conversion in InputStreamReader logic, which will be visible in the full stacktrace - otherwise the conversion error can happen anywhere in the conversion buffer which means that the line/column known to texttablenode isn't truly accurate. Also corrected the distinction that the cause of a TeiidSQLException is not the first chained exception.
> improve texttable error messages
> --------------------------------
>
> Key: TEIID-2621
> URL: https://issues.jboss.org/browse/TEIID-2621
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.4.1, 8.5
>
>
> Not all exceptions from texttable report the line number. Additionally we should be consistent about reporting a 1 based line number and a column number would be useful as well.
--
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
12 years, 7 months
[JBoss JIRA] (TEIID-2621) improve texttable error messages
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-2621:
-------------------------------------
Summary: improve texttable error messages
Key: TEIID-2621
URL: https://issues.jboss.org/browse/TEIID-2621
Project: Teiid
Issue Type: Quality Risk
Components: Query Engine
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 8.4.1, 8.5
Not all exceptions from texttable report the line number. Additionally we should be consistent about reporting a 1 based line number and a column number would be useful as well.
--
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
12 years, 7 months
[JBoss JIRA] (TEIID-247) Add support for array types
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-247?page=com.atlassian.jira.plugin.... ]
Steven Hawkins edited comment on TEIID-247 at 8/13/13 11:01 AM:
----------------------------------------------------------------
Added initial support:
The parser will accept h2 like array expressions:
\(\) or \(,\) - are empty array expressions
\(expr,\) - is a single array value, such that a trailing comma is required
\(expr,...\) - in general where a trailing comma is optional
And the parser will allow the cast to an array type using the standard type names with square braces for the dimensions:
cast\(obj as string[][]\)
And an array element reference expression of:
obj[index]
In ddl:
create view v \(x int[]\) as select \(1,2,3\);
There is minimal validation. And we nominally use a runtime value of ArrayImpl - we use the java array type system to make the values more type safe. So it's not required that the runtime type matches the value type.
For example
\(1,2\) will have a runtime type of integer[]. And we'll understand that \(1,2\)[1] is an integer.
Pushdown support is only enabled for a few jdbc databases - and no import support has yet been implemented. Primitive array values from a source are allowed to remain an primitive array until cast as a typed Teiid array - in which case it will be converted to using wrapper objects.
Known issues:
* Support is just memory based. Large arrays should be avoided. array_agg is hard coded to limit to only 1000 entries.
* Limited Array method support - you cannot yet use the getResultSet methods
* Arrays of lobs will not stream appropriately over a socket transport.
* ODBC arrays are always sent to the client as string arrays.
* multidimensional primitive arrays will not yet convert to typed multidimensional teiid arrays
* casting to/from array types is limited to/from the object type - e.g. casting a 1 dimensional object[] to a 2 dimensional integer array will work, but you cannot yet cast from integer[] to long[].
Additional support may be added under this issue, but in general will be worked as needed. This will include:
* array subquery comparison \(col, col1\) = \(select col, col1 .... \)
* a subquery array constructor
* similar to postgresql the use of ANY, TABLE, and other useful array constructs
* possibly alternative syntax, such as the explicit ARRAY [...] or curly braces.
was (Author: shawkins):
Added initial support:
The parser will accept h2 like array expressions:
\(\) or \(,\) - are empty array expressions
\(expr,\) - is a single array value, such that a trailing comma is required
\(expr,...\) - in general where a trailing comma is optional
And the parser will allow the cast to an array type using the standard type names with square braces for the dimensions:
cast\(obj as string[][]\)
And an array element reference expression of:
obj[index]
In ddl:
create view v \(x int[]\) as select \(1,2,3\);
There is minimal validation. And we nominally use a runtime value of ArrayImpl - we use the java array type system to make the values more type safe. So it's not required that the runtime type matches the value type.
For example
\(1,2\) will have a runtime type of integer[]. And we'll understand that \(1,2\)[1] is an integer.
Pushdown support is only enabled for a few jdbc databases - and no import support has yet been implemented. Primitive array values from a source are allowed to remain an primitive array until cast as a typed Teiid array - in which case it will be converted to using wrapper objects.
Known issues:
* Support is just memory based. Large arrays should be avoided. array_agg is hard coded to limit to only 1000 entries.
* Limited Array method support - you cannot yet use the getResultSet methods
* Arrays of lobs will not stream appropriately over a socket transport.
* ODBC arrays are always sent to the client as string arrays.
Additional support may be added under this issue, but in general will be worked as needed. This will include:
* array subquery comparison \(col, col1\) = \(select col, col1 .... \)
* a subquery array constructor
* similar to postgresql the use of ANY, TABLE, and other useful array constructs
* possibly alternative syntax, such as the explicit ARRAY [...] or curly braces.
> Add support for array types
> ---------------------------
>
> Key: TEIID-247
> URL: https://issues.jboss.org/browse/TEIID-247
> Project: Teiid
> Issue Type: Feature Request
> Components: Connector API, JDBC Driver, Query Engine
> Affects Versions: 6.0.0
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Minor
> Fix For: 8.5
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> Add language support for array types. Push down and client support should also be added.
--
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
12 years, 7 months
[JBoss JIRA] (TEIID-247) Add support for array types
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-247?page=com.atlassian.jira.plugin.... ]
Steven Hawkins updated TEIID-247:
---------------------------------
Fix Version/s: 8.5
Added initial support:
The parser will accept h2 like array expressions:
\(\) or \(,\) - are empty array expressions
\(expr,\) - is a single array value, such that a trailing comma is required
\(expr,...\) - in general where a trailing comma is optional
And the parser will allow the cast to an array type using the standard type names with square braces for the dimensions:
cast\(obj as string[][]\)
And an array element reference expression of:
obj[index]
In ddl:
create view v \(x int[]\) as select \(1,2,3\);
There is minimal validation. And we nominally use a runtime value of ArrayImpl - we use the java array type system to make the values more type safe. So it's not required that the runtime type matches the value type.
For example
\(1,2\) will have a runtime type of integer[]. And we'll understand that \(1,2\)[1] is an integer.
Pushdown support is only enabled for a few jdbc databases - and no import support has yet been implemented. Primitive array values from a source are allowed to remain an primitive array until cast as a typed Teiid array - in which case it will be converted to using wrapper objects.
Known issues:
* Support is just memory based. Large arrays should be avoided. array_agg is hard coded to limit to only 1000 entries.
* Limited Array method support - you cannot yet use the getResultSet methods
* Arrays of lobs will not stream appropriately over a socket transport.
* ODBC arrays are always sent to the client as string arrays.
Additional support may be added under this issue, but in general will be worked as needed. This will include:
* array subquery comparison \(col, col1\) = \(select col, col1 .... \)
* a subquery array constructor
* similar to postgresql the use of ANY, TABLE, and other useful array constructs
* possibly alternative syntax, such as the explicit ARRAY [...] or curly braces.
> Add support for array types
> ---------------------------
>
> Key: TEIID-247
> URL: https://issues.jboss.org/browse/TEIID-247
> Project: Teiid
> Issue Type: Feature Request
> Components: Connector API, JDBC Driver, Query Engine
> Affects Versions: 6.0.0
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Minor
> Fix For: 8.5
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> Add language support for array types. Push down and client support should also be added.
--
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
12 years, 7 months