January 2016 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-3942) Accumulo translators should use LexiCoders to preserve the native ordering

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-3942?page=com.atlassian.jira.plugin... ] Ramesh Reddy updated TEIID-3942: -------------------------------- Fix Version/s: 9.0 8.12.5 > Accumulo translators should use LexiCoders to preserve the native ordering > -------------------------------------------------------------------------- > > Key: TEIID-3942 > URL: https://issues.jboss.org/browse/TEIID-3942 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Affects Versions: 8.12.4 > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Fix For: 9.0, 8.12.5 > > > Accumulo translator currently converts all the data to string based byte array and management of the data types is done at the translator level. In 1.6 version, there is support for LexiCoders which is standard way to encode/decode Java data types. The translator must be changed to make use of these. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3942) Accumulo translators should use LexiCoders to preserve the native ordering

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-3942?page=com.atlassian.jira.plugin... ] Work on TEIID-3942 started by Ramesh Reddy. ------------------------------------------- > Accumulo translators should use LexiCoders to preserve the native ordering > -------------------------------------------------------------------------- > > Key: TEIID-3942 > URL: https://issues.jboss.org/browse/TEIID-3942 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Affects Versions: 8.12.4 > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Fix For: 9.0, 8.12.5 > > > Accumulo translator currently converts all the data to string based byte array and management of the data types is done at the translator level. In 1.6 version, there is support for LexiCoders which is standard way to encode/decode Java data types. The translator must be changed to make use of these. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3921) Accumulo translator doesn't end query execution when there are no tablet servers

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-3921?page=com.atlassian.jira.plugin... ] Work on TEIID-3921 started by Ramesh Reddy. ------------------------------------------- > 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 > > 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 (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3930) Accumulo translator: select rowid returns empty resultset

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-3930?page=com.atlassian.jira.plugin... ] Work on TEIID-3930 started by Ramesh Reddy. ------------------------------------------- > Accumulo translator: select rowid returns empty resultset > --------------------------------------------------------- > > Key: TEIID-3930 > URL: https://issues.jboss.org/browse/TEIID-3930 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.12.3 > Reporter: Jan Stastny > Assignee: Ramesh Reddy > > Accumulo translator, according to its [documentation|https://docs.jboss.org/author/display/teiid812final/Apache+...], enables querying accumulo through teiid's vdb with table like: > {code:xml} > CREATE FOREIGN TABLE "User" ( > rowid string OPTIONS (UPDATABLE FALSE, SEARCHABLE 'All_Except_Like'), > name_age string OPTIONS (SEARCHABLE 'All_Except_Like', "teiid_accumulo:CF" 'name', "teiid_accumulo:CQ" 'age', "teiid_accumulo:VALUE-IN" '{VALUE}'), > name_firstname string OPTIONS (SEARCHABLE 'All_Except_Like', "teiid_accumulo:CF" 'name', "teiid_accumulo:CQ" 'firstname', "teiid_accumulo:VALUE-IN" '{VALUE}'), > name_lastname string OPTIONS (SEARCHABLE 'All_Except_Like', "teiid_accumulo:CF" 'name', "teiid_accumulo:CQ" 'lastname', "teiid_accumulo:VALUE-IN" '{VALUE}'), > CONSTRAINT PK0 PRIMARY KEY(rowid) > ) OPTIONS (UPDATABLE TRUE); > {code} > The problem is, that querying for rowid column won't return any results: > Query > {code:sql} > SELECT rowid FROM User; > {code} > does return empty resultset. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3933) Accumulo translator: problem comparing number literals

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-3933?page=com.atlassian.jira.plugin... ] Work on TEIID-3933 started by Ramesh Reddy. ------------------------------------------- > 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 > > 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 (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3894) Teiid transport ssl attributes should add some default values

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3894?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-3894: ---------------------------------- Fix Version/s: 9.0 8.12.5 (was: 9.x) Affects Version/s: (was: 9.x) > Teiid transport ssl attributes should add some default values > ------------------------------------------------------------- > > Key: TEIID-3894 > URL: https://issues.jboss.org/browse/TEIID-3894 > Project: Teiid > Issue Type: Feature Request > Components: Server > Reporter: Kylin Soong > Assignee: Steven Hawkins > Fix For: 9.0, 8.12.5 > > > Execute the following cli > {code} > /subsystem=teiid/transport=jdbc:write-attribute(name=ssl-mode,value=enabled) > /subsystem=teiid/transport=jdbc:write-attribute(name=ssl-authentication-mode,value=1-way) > /subsystem=teiid/transport=jdbc:write-attribute(name=ssl-ssl-protocol,value=TLSv1) > /subsystem=teiid/transport=jdbc:write-attribute(name=ssl-keymanagement-algorithm,value=SunX509) > /subsystem=teiid/transport=jdbc:write-attribute(name=ssl-enabled-cipher-suites,value="SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA") > /subsystem=teiid/transport=jdbc:write-attribute(name=keystore-type,value=JKS) > {code} > no suggested value pop up, some values only allow existed value, so I think add some default value is necessary. > h3. ssl-mode allowed value > * enabled > * login > * enabled > h3. ssl-authentication-mode allowed value > * 1-way > * 2-way > * anonymous > h3. ssl-ssl-protocol default value > * TLSv1 > h3. ssl-keymanagement-algorithm default value > * SunX509 > h3. ssl-enabled-cipher-suites default value > * SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA > h3. keystore-type default value > * JKS -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3938) EdmDate and EdmTimeOfDay output in local timezone

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3938?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3938: --------------------------------------- This highlights the issue with EdmDate: TimeZone.setDefault(TimeZone.getTimeZone("GMT-1")); java.sql.Timestamp date = EdmDate.getInstance().valueOfString("2000-01-01", true, 4000, 0, 0, true, java.sql.Timestamp.class); assertEquals("1999-12-31 23:00:00.0", date.toString()); String val = EdmDate.getInstance().valueToString(date, true, 4000, 0, 0, true); assertEquals("2000-01-01", date.toString()); The last line fails because the date will be "1999-12-31" instead. > EdmDate and EdmTimeOfDay output in local timezone > ------------------------------------------------- > > Key: TEIID-3938 > URL: https://issues.jboss.org/browse/TEIID-3938 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Fix For: 8.12.5 > > > EdmDate and EdmTimeOfDay both assume GMT for incoming string values - however when the convert from Java objects to string they use the local/default Calendar. So when Teiid is on a server not in GMT date and time value sent via the odata4 translator will likely be wrong. > Ramesh: > I have posted a question to the Olingo development group here http://markmail.org/search/list:org.apache.olingo.dev#query:list%3Aorg.ap... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3938) EdmDate and EdmTimeOfDay output in local timezone

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-3938?page=com.atlassian.jira.plugin... ] Ramesh Reddy reassigned TEIID-3938: ----------------------------------- Assignee: Ramesh Reddy (was: Steven Hawkins) > EdmDate and EdmTimeOfDay output in local timezone > ------------------------------------------------- > > Key: TEIID-3938 > URL: https://issues.jboss.org/browse/TEIID-3938 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Fix For: 8.12.5 > > > EdmDate and EdmTimeOfDay both assume GMT for incoming string values - however when the convert from Java objects to string they use the local/default Calendar. So when Teiid is on a server not in GMT date and time value sent via the odata4 translator will likely be wrong. > Ramesh: > I have posted a question to the Olingo development group here http://markmail.org/search/list:org.apache.olingo.dev#query:list%3Aorg.ap... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3938) EdmDate and EdmTimeOfDay output in local timezone

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-3938?page=com.atlassian.jira.plugin... ] Ramesh Reddy updated TEIID-3938: -------------------------------- Fix Version/s: 8.12.5 > EdmDate and EdmTimeOfDay output in local timezone > ------------------------------------------------- > > Key: TEIID-3938 > URL: https://issues.jboss.org/browse/TEIID-3938 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Fix For: 8.12.5 > > > EdmDate and EdmTimeOfDay both assume GMT for incoming string values - however when the convert from Java objects to string they use the local/default Calendar. So when Teiid is on a server not in GMT date and time value sent via the odata4 translator will likely be wrong. > Ramesh: > I have posted a question to the Olingo development group here http://markmail.org/search/list:org.apache.olingo.dev#query:list%3Aorg.ap... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3816) Informix translator - <> ALL is translated as NOT IN - this statement seem to not work in Infromix

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3816?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-3816. ----------------------------------- Fix Version/s: (was: 8.12.x) Resolution: Won't Fix Added a KI into the release notes. > Informix translator - <> ALL is translated as NOT IN - this statement seem to not work in Infromix > -------------------------------------------------------------------------------------------------- > > Key: TEIID-3816 > URL: https://issues.jboss.org/browse/TEIID-3816 > Project: Teiid > Issue Type: Bug > Affects Versions: 8.7.2.6_2 > Reporter: Juraj Duráni > Assignee: Steven Hawkins > > Query: > {code:sql} > SELECT INTKEY, BOOLEANVALUE FROM BQT1.SMALLA WHERE BOOLEANVALUE <> ALL (SELECT BOOLEANVALUE FROM BQT1.SMALLA WHERE INTKEY = 40) > {code} > Source-specific command: > {code:sql} > SELECT g_0.IntKey, g_0.BooleanValue FROM Source.SmallA AS g_0 WHERE g_0.BooleanValue NOT IN (SELECT g_1.BooleanValue FROM Source.SmallA AS g_1 WHERE g_1.IntKey = 40) > {code} > *Note: boolean value for row where Intkey = 40 is false.* > Expected result: > |intkey|booleanvalue| > |1|true| > |...|...| > Actual result: > |intkey|booleanvalue| > |0|false| > |...|...| > This seems to be an Informix issue as neither '<> ALL' nor 'NOT IN' works. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues January 2016