[JBoss JIRA] (TEIID-3050) allow for more incremental insert with iterator
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3050?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-3050.
---------------------------------
> allow for more incremental insert with iterator
> -----------------------------------------------
>
> Key: TEIID-3050
> URL: https://issues.jboss.org/browse/TEIID-3050
> Project: Teiid
> Issue Type: Enhancement
> Components: Misc. Connectors, Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.0, 8.12.5, 8.13.3
>
>
> The current bulk insert logic assumes that it is avoiding a global transactions by fully reading the results before sending the tuplebuffer iterator to the source for processing, which can then just use a local transaction. However if we are already operating under a transaction or the user doesn't want a transaction (such as with a staging materialized view load) then the insert should happen more incrementally.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (TEIID-4041) OData response does not contain header "allow"
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4041?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-4041.
---------------------------------
> OData response does not contain header "allow"
> ----------------------------------------------
>
> Key: TEIID-4041
> URL: https://issues.jboss.org/browse/TEIID-4041
> Project: Teiid
> Issue Type: Sub-task
> Components: OData
> Reporter: Juraj Duráni
> Assignee: Ramesh Reddy
> Fix For: 9.0, 8.12.5
>
>
> If user sends request to URL with unsupported HTTP method, OData service should return allowed methods in header _allow_.
> *URL:* http://localhost:8080/odata4/olingo_basic/Source/SimpleTableView/
> *Method:* DELETE
> *Response headers:* date=Wed, 09 Mar 2016 08:21:17 GMT, server=Apache-Coyote/1.1, content-length=192, expires=Thu, 01 Jan 1970 00:00:00 GMT+00:00, content-type=application/xml, cache-control=no-cache, pragma=No-cache, odata-version=4.0
> See http://docs.oasis-open.org/odata/odata/v4.0/errata02/os/complete/part1-pr...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (TEIID-4112) ORA-32039: recursive WITH clause must have column alias list
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4112?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-4112.
---------------------------------
> ORA-32039: recursive WITH clause must have column alias list
> ------------------------------------------------------------
>
> Key: TEIID-4112
> URL: https://issues.jboss.org/browse/TEIID-4112
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector, Query Engine
> Affects Versions: 8.7.2.6_2
> Reporter: Debbie Steigner
> Assignee: Steven Hawkins
> Fix For: 9.0, 8.12.5, 8.7.6.6_2
>
>
> If running a WITH table AS(...) query to Oracle and the query schema name is the same as the subquery name i.e. EWI. you receive the Oracle error:
> ORA-32039: recursive WITH clause must have column alias list
> If you modify the query to
> WITH EWI1 AS ....
> then it works.
> f.ex:
> breaking: WITH tbl AS (
> where tbl = a common table name in the current schema and the common table definition as (...) references a view in that schema. Oracle will complain with this erroneous error.
> work-around: WITH tbl_1 AS(
> where tbl_1 does not exist as a current schema/table name.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (TEIID-3933) Accumulo translator: problem comparing number literals
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3933?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-3933.
---------------------------------
> Accumulo translator: problem comparing number literals
> ------------------------------------------------------
>
> Key: TEIID-3933
> URL: https://issues.jboss.org/browse/TEIID-3933
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.3
> Reporter: Jan Stastny
> Assignee: Ramesh Reddy
> Fix For: 9.0, 8.12.5
>
>
> When accessing Accumulo instance using accumulo translator with table DDL defined in the model's metadata, there are problems filtering the output in from clause.
> For example, when there is a comparison between a column of type long with literal value 3, an exception, whose cause is below, is thrown on accumulo's side:
> {code:sql}
> SELECT * FROM accumulo.SmallA WHERE LongNum>3
> {code}
> {code:plain}
> Caused by: java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Long
> at java.lang.Long.compareTo(Long.java:50)
> at org.teiid.query.sql.symbol.Constant$2.compare(Constant.java:99)
> at org.teiid.query.eval.Evaluator.compare(Evaluator.java:645)
> at org.teiid.query.eval.Evaluator.evaluate(Evaluator.java:373)
> at org.teiid.query.eval.Evaluator.internalEvaluateTVL(Evaluator.java:237)
> at org.teiid.query.eval.Evaluator.evaluateTVL(Evaluator.java:226)
> at org.teiid.query.eval.Evaluator.evaluate(Evaluator.java:220)
> at org.teiid.translator.accumulo.EvaluatorIterator.acceptRow(EvaluatorIterator.java:229)
> at org.teiid.translator.accumulo.EvaluatorIterator.filter(EvaluatorIterator.java:184)
> at org.teiid.translator.accumulo.EvaluatorIterator.prepKeys(EvaluatorIterator.java:180)
> at org.teiid.translator.accumulo.EvaluatorIterator.seek(EvaluatorIterator.java:159)
> at org.apache.accumulo.core.iterators.WrappingIterator.seek(WrappingIterator.java:101)
> at org.apache.accumulo.core.iterators.user.VersioningIterator.seek(VersioningIterator.java:81)
> at org.apache.accumulo.core.iterators.system.SourceSwitchingIterator.readNext(SourceSwitchingIterator.java:116)
> at org.apache.accumulo.core.iterators.system.SourceSwitchingIterator.seek(SourceSwitchingIterator.java:168)
> at org.apache.accumulo.server.tabletserver.Tablet.nextBatch(Tablet.java:1737)
> at org.apache.accumulo.server.tabletserver.Tablet.access$3200(Tablet.java:152)
> at org.apache.accumulo.server.tabletserver.Tablet$Scanner.read(Tablet.java:1879)
> at org.apache.accumulo.server.tabletserver.TabletServer$ThriftClientHandler$NextBatchTask.run(TabletServer.java:945)
> at org.apache.accumulo.trace.instrument.TraceRunnable.run(TraceRunnable.java:47)
> {code}
> but when I provide a value higher, than can be saved in integer, thus the type of the literal is inferred as long, the query runs as expected.
> {code:sql}
> SELECT * FROM accumulo.SmallA WHERE LongNum>30000000000000000000
> {code}
> Similar problems I had with
> ||Column type||Literal||Inferred type||Rootcause message||
> |long|3|Integer|java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Long|
> |biginteger|3|Integer|java.lang.ClassCastException: java.lang.Integer cannot be cast to java.math.BigInteger|
> |double|3.0|BigDecimal|java.lang.ClassCastException: java.math.BigDecimal cannot be cast to java.lang.Double|
> |float|3.0|BigDecimal|java.lang.ClassCastException: java.math.BigDecimal cannot be cast to java.lang.Float|
> rest of the cause's stacktrace look the same.
> In Squirrel I get:
> {code:plain}
> TEIID30504 Remote org.teiid.core.TeiidProcessingException: TEIID30504 node-one: Error on server 127.0.0.1:9997
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (TEIID-3921) Accumulo translator doesn't end query execution when there are no tablet servers
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3921?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-3921.
---------------------------------
> Accumulo translator doesn't end query execution when there are no tablet servers
> --------------------------------------------------------------------------------
>
> Key: TEIID-3921
> URL: https://issues.jboss.org/browse/TEIID-3921
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.3
> Reporter: Jan Stastny
> Assignee: Ramesh Reddy
> Fix For: 9.0, 8.12.5
>
>
> Teiid accumulo translator doesn't interrupt query execution when the accumulo instance is not running.
> There might be a situation that Zookeeper instance is running, but Accumulo is not.
> The translator, even though there is no tablet server entry in zookeeper, for given accumulo instance, executes the query. The query is running until query timeout exceeds. There is no indication of the fact, that accumulo tablet server is not present/responding except for
> {code}
> 09:25:46,539 WARN [org.apache.accumulo.core.client.impl.ServerClient] (Worker3_QueryProcessorQueue21) There are no tablet servers: check that zookeeper and accumulo are running.
> {code}
> There might be even situation, that Accumulo stopped in unusual way and didn't alter the tablet server information in Zookeeper, this way, there is a tablet server entry present in Zookeeper, but the tablet server is in fact not running. So Teiid should check the tablet server's address which received from Zookeeper.
> Interesting to note is the fact, that the same problem can be examined in accumulo's shell:
> {code}
> $ bin/accumulo shell -u root
> Password: ******
> 2016-01-22 10:02:05,604 [impl.ServerClient] WARN : There are no tablet servers: check that zookeeper and accumulo are running.
> {code}
> and then the shell hangs. Teiid needs to overcome this limitation.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (TEIID-4471) Assertion error with temp table delete
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4471?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-4471.
---------------------------------
> Assertion error with temp table delete
> --------------------------------------
>
> Key: TEIID-4471
> URL: https://issues.jboss.org/browse/TEIID-4471
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 9.1, 8.13.7, 9.0.4
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.1, 8.13.7, 9.0.5, 8.12.8.6_3
>
>
> Related to TEIID-4405 there are circumstances where a temp table deletion results in an assertion error of "delete failed". A possible scenario (that is dependent upon a number of factors, including batch sizes and garbage collection) requires the values stored by the tuple browser to get out of sync with what is stored by the page such that a delete is attempted twice.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months