May 2015 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-3133) Impala Time/Date/Timestamp handling

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3133?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3133: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1207220|https://bugzilla.redhat.com/show_bug.cgi?id=1207220] from MODIFIED to ON_QA > Impala Time/Date/Timestamp handling > ----------------------------------- > > Key: TEIID-3133 > URL: https://issues.jboss.org/browse/TEIID-3133 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.7.1 > Reporter: Van Halbert > Assignee: Steven Hawkins > Fix For: 8.7.1, 8.9, 8.7.2 > > > Impala supports only TIMESTAMP datatype (see here http://www.cloudera.com/content/cloudera-content/cloudera-docs/CDH5/lates...) > Converted everything into timestamp and now I am trying to get Date and Time parts of the timestamp in Teiid e.g. > SELECT DISTINCT convert(Source.SmallA.TimeValue, time) as TimeValue FROM Source.SmallA ORDER BY TimeValue > But I get TranslatorException: Unexpected exception while translating results: Method not supported > Tried to workaround this but with limited success. For Date it is possible to use to_date function that returns string reprsentation of the date part. For Time I wasn't able to find the solution (have not yet figured out how to use extract function through Teiid). > http://www.cloudera.com/content/cloudera-content/cloudera-docs/CDH5/lates... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3187) Error Casting TimeStamp to Date using Impala

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3187?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3187: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1207220|https://bugzilla.redhat.com/show_bug.cgi?id=1207220] from MODIFIED to ON_QA > Error Casting TimeStamp to Date using Impala > -------------------------------------------- > > Key: TEIID-3187 > URL: https://issues.jboss.org/browse/TEIID-3187 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.7.1 > Reporter: Van Halbert > Assignee: Steven Hawkins > Fix For: 8.7.1, 8.9.1, 8.10 > > > With ER3 getting [1] for the conversion of a timestamp to a Date: > convert(Source.smalla.DATEVALUE, date) AS DateValue > [1] > org.teiid.jdbc.TeiidSQLException: TEIID30504 Remote org.teiid.core.TeiidProcessingException: TEIID30504 Source: 0 TEIID11008:TEIID11004 Error executing statement(s): [Prepared Values: [] SQL: SELECT DISTINCT cast(g_0.DATEVALUE AS date) AS c_0 FROM smalla g_0 ORDER BY c_0] > at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:135) > at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:71) > at org.teiid.jdbc.StatementImpl.postReceiveResults(StatementImpl.java:667) > at org.teiid.jdbc.StatementImpl.access$100(StatementImpl.java:63) > at org.teiid.jdbc.StatementImpl$2.onCompletion(StatementImpl.java:515) > at org.teiid.client.util.ResultsFuture.done(ResultsFuture.java:135) > at org.teiid.client.util.ResultsFuture.access$200(ResultsFuture.java:40) > at org.teiid.client.util.ResultsFuture$1.receiveResults(ResultsFuture.java:79) > at org.teiid.net.socket.SocketServerInstanceImpl.receivedMessage(SocketServerInstanceImpl.java:264) > at org.teiid.net.socket.SocketServerInstanceImpl.read(SocketServerInstanceImpl.java:302) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.teiid.net.socket.SocketServerConnectionFactory$ShutdownHandler.invoke(SocketServerConnectionFactory.java:98) > at com.sun.proxy.$Proxy1.read(Unknown Source) > at org.teiid.net.socket.SocketServerInstanceImpl$RemoteInvocationHandler$1.get(SocketServerInstanceImpl.java:401) > at org.teiid.jdbc.StatementImpl.executeSql(StatementImpl.java:524) > at org.teiid.jdbc.StatementImpl.executeSql(StatementImpl.java:393) > at org.teiid.jdbc.StatementImpl.executeQuery(StatementImpl.java:327) > at JDBCClient.execute(JDBCClient.java:80) > at JDBCClient.main(JDBCClient.java:46) > Caused by: org.teiid.core.TeiidProcessingException: TEIID30504 Remote org.teiid.core.TeiidProcessingException: TEIID30504 Source: 0 TEIID11008:TEIID11004 Error executing statement(s): [Prepared Values: [] SQL: SELECT DISTINCT cast(g_0.DATEVALUE AS date) AS c_0 FROM smalla g_0 ORDER BY c_0] > at org.teiid.dqp.internal.process.DataTierTupleSource.exceptionOccurred(DataTierTupleSource.java:381) > at org.teiid.dqp.internal.process.DataTierTupleSource.nextTuple(DataTierTupleSource.java:154) > at org.teiid.query.processor.relational.AccessNode.nextBatchDirect(AccessNode.java:369) > at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278) > at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:136) > at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:151) > at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114) > at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:159) > at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:141) > at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:444) > at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:326) > at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51) > at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:254) > at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:274) > at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) > at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.teiid.core.TeiidException: 0 Remote org.teiid.translator.jdbc.JDBCExecutionException: 0 TEIID11008:TEIID11004 Error executing statement(s): [Prepared Values: [] SQL: SELECT DISTINCT cast(g_0.DATEVALUE AS date) AS c_0 FROM smalla g_0 ORDER BY c_0] > at org.teiid.translator.jdbc.JDBCQueryExecution.execute(JDBCQueryExecution.java:131) > at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:325) > at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:298) > at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:110) > at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:107) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:58) > ... 6 more > Caused by: java.sql.SQLException: Remote java.sql.SQLException: AnalysisException: Invalid type cast of g_0.DATEVALUE from TIMESTAMP to DATE -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3368) The database-service.jar needs version version in its name

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3368?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3368: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1199048|https://bugzilla.redhat.com/show_bug.cgi?id=1199048] from MODIFIED to ON_QA > The database-service.jar needs version version in its name > ---------------------------------------------------------- > > Key: TEIID-3368 > URL: https://issues.jboss.org/browse/TEIID-3368 > Project: Teiid > Issue Type: Bug > Components: Tools > Affects Versions: 8.7.1, 8.11 > Reporter: Van Halbert > Assignee: Van Halbert > Fix For: 8.10 > > > The database-service.jar in the tepid-extensions needs to be built with a version in the name. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3422) Setting more than 513MB for buffer-service-max-storage-object-size, OOME occurs at org.teiid.common.buffer.impl.BufferFrontedFileStoreCache.initialize()

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3422?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3422: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1210714|https://bugzilla.redhat.com/show_bug.cgi?id=1210714] from MODIFIED to ON_QA > Setting more than 513MB for buffer-service-max-storage-object-size, OOME occurs at org.teiid.common.buffer.impl.BufferFrontedFileStoreCache.initialize() > -------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: TEIID-3422 > URL: https://issues.jboss.org/browse/TEIID-3422 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.7 > Environment: JBoss DV 6.0, 6.1 > Reporter: hisao furuichi > Assignee: Steven Hawkins > Fix For: 8.7.1.6_2, 8.11 > > > Setting more than 513MB for buffer-service-max-storage-object-size, OOME occurs at org.teiid.common.buffer.impl.BufferFrontedFileStoreCache.initialize(). > One of our user needs to set more than 512MB for buffer-service-max-storage-object-size to avoid TEIID30001[1], this limitation becomes a critical issue for them. > Additional Information: > By taking look at the source code[2], if the value of maxStorageObjectSize is more than equals with 536870912, the loop becomes infinit, and will cause OOME. > [1] > TEIID30001 Max block number exceeded by 233,144 21,422,155. Increase the maxStorageObjectSize to support larger storage objects. Alternatively you could make the processor batch size smaller. > [2]teiid/engine/src/main/java/org/teiid/common/buffer/impl/BufferFrontedFileStoreCache.java > === > public static final long MAX_ADDRESSABLE_MEMORY = 1l<<(ADDRESS_BITS+LOG_BLOCK_SIZE); > ~~ > static final int BLOCK_SIZE = 1 << LOG_BLOCK_SIZE; > ~~ > public void initialize() throws TeiidComponentException { > ~~ > List<BlockStore> stores = new ArrayList<BlockStore>(); > int size = BLOCK_SIZE; > int files = 32; //this allows us to have 64 terabytes of smaller block sizes > do { > stores.add(new BlockStore(this.storageManager, size, 30, files)); > size <<=1; > if (files > 1) { > files >>= 1; > } > } while ((size>>1) < maxStorageObjectSize); > ~~ > === -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3358) Issues with entity set names

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3358?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3358: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1208515|https://bugzilla.redhat.com/show_bug.cgi?id=1208515] from MODIFIED to ON_QA > Issues with entity set names > ---------------------------- > > Key: TEIID-3358 > URL: https://issues.jboss.org/browse/TEIID-3358 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 8.7 > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Labels: Alpha1 > Fix For: 8.7.1.6_2, 8.11 > > > The entity set name used for sql generation should be the fully qualified name. If there is for example two table with the same names in schemas visible to odata, but one of the tables does not have a key, then an ambiguous name exception will be thrown if an odata url is used with only the base table name. > It also appears that the URI link in the results metadata uses the non-qualified table name, which will have issues in the scenario above. > We may also need to document or add an additional check for ambiguity as the OData4j findEdmEntitySet logic will return the first matching entity, which is generally against our approach to resolving. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3410) OData object URI does not resolve to a usable URL.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3410?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3410: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1208515|https://bugzilla.redhat.com/show_bug.cgi?id=1208515] from MODIFIED to ON_QA > OData object URI does not resolve to a usable URL. > -------------------------------------------------- > > Key: TEIID-3410 > URL: https://issues.jboss.org/browse/TEIID-3410 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 8.7 > Reporter: Debbie Steigner > Assignee: Steven Hawkins > > OData object URI does not resolve to a usable URL. When accessing a VDB via odata with a browser either via JSON or XML the uri listed in the metadata is not valid, it doesn't have the FQN of the table, only the type shows FQN: > "__metadata" : { > "uri" : "http://localhost:8080/odata/ODataRHQ/rhq_agent(10001)", > "type" : "RHQ32.rhq_agent" -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3462) Add support for semantic versioning of VDBs

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3462?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3462: --------------------------------------- Added as a 9.0/9.x issue. For the 8.x series the workarounds mentioned above should be used. > Add support for semantic versioning of VDBs > ------------------------------------------- > > Key: TEIID-3462 > URL: https://issues.jboss.org/browse/TEIID-3462 > Project: Teiid > Issue Type: Feature Request > Components: Server > Affects Versions: 8.7 > Reporter: Marc Shirley > Assignee: Steven Hawkins > Fix For: 9.0 > > > Semantic versioning [1] should be supported in the VDB versioning in order to be able to easier determine whether there are breaking changes from the client perspective and to more easily establish a link between client software versions and the VDBs they rely upon. > [1] http://semver.org/ -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3462) Add support for semantic versioning of VDBs

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3462?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-3462: ---------------------------------- Fix Version/s: 9.0 > Add support for semantic versioning of VDBs > ------------------------------------------- > > Key: TEIID-3462 > URL: https://issues.jboss.org/browse/TEIID-3462 > Project: Teiid > Issue Type: Feature Request > Components: Server > Affects Versions: 8.7 > Reporter: Marc Shirley > Assignee: Steven Hawkins > Fix For: 9.0 > > > Semantic versioning [1] should be supported in the VDB versioning in order to be able to easier determine whether there are breaking changes from the client perspective and to more easily establish a link between client software versions and the VDBs they rely upon. > [1] http://semver.org/ -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3429) Provide hooks to interrogate metadata prior to full import

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3429?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3429: --------------------------------------- > For (2) you will be developing a new MetadataFactory that understands the translator level "getCatalog" kind methods. or modify the DDL Metadata Factory to do the same with help of some flag. Neither. Again I don't think this metadata task fits well with our current MetadataFactory/MetadataProcessor logic. Instead it's the translator that is exposing procedures that provide access to underlying metadata facilities. The only thing that we may need to do on top of that is to expose the potential runtime name for using include/exclude. > I thought using both JDBC and Admin interfaces for what looks like single task for user prespective is not good. Other than that I do not have any other objections Again unless we want to have this done in a vdb-less way, I don't see much advantage of using the admin interface. > Provide hooks to interrogate metadata prior to full import > ----------------------------------------------------------- > > Key: TEIID-3429 > URL: https://issues.jboss.org/browse/TEIID-3429 > Project: Teiid > Issue Type: Feature Request > Components: Server > Reporter: Steven Hawkins > Assignee: Steven Hawkins > > To support the Desinger we should offer the ability to interrogate metadata prior to full import. > Exploring metadata is effectively an entirely different mode of operation with respect to the current metadata processing logic on the Teiid side. Also partial metadata isn't something that would neatly be expressed through DDL - tables without columns, a list of schema names, etc. > Ways around that would be to expose source procedures for metadata interrogation: > > getTableNames - which would probably give both the Teiid name and the name in source and consider the current translator metadata settings > getProcedureNames > And importer specific info such as for JDBC getTableTypes, getCatalogNames, getSchemaNames > > I'd want to keep it fairly high level though. Getting column or key information I'd expect would be done through the normal full import. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3463) Add an importer for LDAP

by Kylin Soong (JIRA)

[ https://issues.jboss.org/browse/TEIID-3463?page=com.atlassian.jira.plugin... ] Kylin Soong updated TEIID-3463: ------------------------------- Attachment: ldap-ds-1.png ldap-ds-2.png ldap-ds-3.png As attached png, I tried import LDAP service -> Source Model in Teiid Designer, it hit a validation error as ldap-ds-3.png that block to do further import. I also find there no MetadataProcessor implementation in 'translator-ldap', does this the reason for block import to process? > Add an importer for LDAP > ------------------------ > > Key: TEIID-3463 > URL: https://issues.jboss.org/browse/TEIID-3463 > Project: Teiid > Issue Type: Feature Request > Components: LDAP Connector > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Attachments: ldap-ds-1.png, ldap-ds-2.png, ldap-ds-3.png > > > Related to TEIIDDES-2499, Teiid should add import support for LDAP. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 5 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues May 2015