June 2018 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-5332) Change JDG translator/connector to package the jars and include in distro

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-5332?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated TEIID-5332: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1572204, https://bugzilla.redhat.com/show_bug.cgi?id=1585711 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1572204) > Change JDG translator/connector to package the jars and include in distro > ------------------------------------------------------------------------- > > Key: TEIID-5332 > URL: https://issues.jboss.org/browse/TEIID-5332 > Project: Teiid > Issue Type: Enhancement > Components: Infinispan > Affects Versions: 8.12.12.6_4 > Reporter: Van Halbert > Assignee: Van Halbert > Priority: Blocker > > JDG will be deprecating their 7.1 images and moving to 7.2. So that the JDG translator can support 7.1 and future patching, JDV needs to package the jar's, instead of relying on the deprecated 7.1 client. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5363) SimpleDB connector not quoting table names in internal Select queries

by Pranav K (JIRA)

Pranav K created TEIID-5363: ------------------------------- Summary: SimpleDB connector not quoting table names in internal Select queries Key: TEIID-5363 URL: https://issues.jboss.org/browse/TEIID-5363 Project: Teiid Issue Type: Bug Reporter: Pranav K Assignee: Steven Hawkins Facing an issue while querying the Simple DB connector for a specific type of tables - the tables that contain a hyphen in the name. According to the SimpleDB documentation: Attribute and domain names may appear without quotes if they contain only letters, numbers, underscores (_), or dollar symbols ($) and do not start with a number. You must quote all other attribute and domain names with the backtick (`). (https://docs.aws.amazon.com/AmazonSimpleDB/latest/DeveloperGuide/QuotingR...) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5362) Odata4 outputs in wrong timezone

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5362?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5362: --------------------------------------- Also this doesn't seem directly related to OData - the behavior should be confirmed with just JDBC queries as well. > Odata4 outputs in wrong timezone > -------------------------------- > > Key: TEIID-5362 > URL: https://issues.jboss.org/browse/TEIID-5362 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 8.12.13.6_4 > Reporter: Debbie Steigner > Assignee: Steven Hawkins > > The incoming odata4 request is requesting the records at 08:52Z (specifying UTC time). The DataVirt server (running in US/Chicago time) converts that into SQL to ask the database for records at 03:52 (with no timezone specifier... should be in local time, or US/Chicago). The database should recognize that the 03:52 Local time should be converted back to 08:52Z to match the DB records, however, it is not. This (and other tests), leads us to the conclusion that the database session/connection is actually not using US/Chicago (-5:00) timezone, but is instead using the UTC timezone. Unfortunately, we were not able to confirm either in the logs or in the configuration, where the connection was being set up in UTC timezone. > . -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5362) Odata4 outputs in wrong timezone

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5362?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5362: --------------------------------------- Which database is this? Generally the driver will handle necessary conversions. Also for JDBC there is the databaseTimezone property that may be relevant. > Odata4 outputs in wrong timezone > -------------------------------- > > Key: TEIID-5362 > URL: https://issues.jboss.org/browse/TEIID-5362 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 8.12.13.6_4 > Reporter: Debbie Steigner > Assignee: Steven Hawkins > > The incoming odata4 request is requesting the records at 08:52Z (specifying UTC time). The DataVirt server (running in US/Chicago time) converts that into SQL to ask the database for records at 03:52 (with no timezone specifier... should be in local time, or US/Chicago). The database should recognize that the 03:52 Local time should be converted back to 08:52Z to match the DB records, however, it is not. This (and other tests), leads us to the conclusion that the database session/connection is actually not using US/Chicago (-5:00) timezone, but is instead using the UTC timezone. Unfortunately, we were not able to confirm either in the logs or in the configuration, where the connection was being set up in UTC timezone. > . -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5265) AssertionError: Batch not found in storage

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-5265?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-5265: --------------------------------- Fix Version/s: 8.12.14.6_4 > AssertionError: Batch not found in storage > ------------------------------------------ > > Key: TEIID-5265 > URL: https://issues.jboss.org/browse/TEIID-5265 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 10.1 > Reporter: Bram Gadeyne > Assignee: Steven Hawkins > Fix For: 10.2, 10.1.3, 8.12.14.6_4 > > > While executing the following query: > {code:sql} > insert into rep149_cci(PatientID,age,Orig,Upd,agepointsO,agepointsU,AMI,CHF,PVD,CVD,DEM,CPD,PUD,MLD,SLD,DNC,DWC,HEM,RED,MAL,MST,HIV) > select cci.patientid as patientid,cci.age as age,cci.orig as orig,cci.upd as upd,cci.agepointso as agepointso,cci.agepointsu as agepointsu, > cci.charlson_ami as ami,cci.charlson_chf as chf,cci.charlson_pvd as pvd,cci.charlson_cvd as cvd,cci.charlson_dem as dem,cci.charlson_cpd as cpd,cci.charlson_pud as pud, > cci.charlson_mld as mld,cci.charlson_sld as sld,cci.charlson_dnc as dnc,cci.charlson_dwc as dwc,cci.charlson_hem as hem,cci.charlson_red as red,cci.charlson_mal as mal, > cci.charlson_mst as mst,cci.charlson_hiv as hiv > from rep149_cohort gd > join izisviews.pr_calculate_cci cci on > cci.patientid_in = gd.patientid; > {code} > rep149_cci is defined as > {code:sql} > create foreign temporary table rep149_cci( > PatientID integer not null, > age bigdecimal, > Orig long, > Upd long, > agepointsO integer, > agepointsU integer, > AMI integer, > CHF integer, > PVD integer, > CVD integer, > DEM integer, > CPD integer, > PUD integer, > MLD integer, > SLD integer, > DNC integer, > DWC integer, > HEM integer, > RED integer, > MAL integer, > MST integer, > HIV integer, > primary key(patientid) > )OPTIONS (UPDATABLE true) on tmptables; > {code} > pr_calculate_cci is a virtual procedure. (I can't however share this code for confidentiality reasons). > {code:sql} > CREATE VIRTUAL PROCEDURE pr_calculate_cci(patientid_in integer) > RETURNS ( > PatientID integer, > age bigdecimal, > Orig long, > Upd long, > agepointsO integer, > agepointsU integer, > AMI integer, > CHF integer, > PherVascDis integer, > CerebVascDis integer, > Dement integer, > ChrPulmDis integer, > PeptUlcer integer, > MildLivDis integer, > SevLivDis integer, > DiabetesNoCompl integer, > DiabetesWithCompl integer, > HemiPara integer, > RenalDis integer, > Malign integer, > Metastase integer, > HIV_AIDS integer > ) > AS > BEGIN > ... > END > {code} > There are a few error reports like this one: > 2018-02-23 08:33:05,478 ERROR [org.teiid.BUFFER_MGR] (Worker291_QueryProcessorQueue571476) mh0bsTIbs7qY TEIID30001 Max block number exceeded by object 1,366,497 from group 5,068,016. It is a Batch of 1797 rows of [Ljava.lang.String;@10953478. The estimated size was 172,528, but the actual size was 14,410. Increase the maxStorageObjectSize to support larger storage objects. Alternatively you could make the processor batch size smaller. > The final stack trace is: > 2018-02-23 08:33:05,539 ERROR [org.teiid.PROCESSOR] (Worker291_QueryProcessorQueue571476) mh0bsTIbs7qY TEIID30019 Unexpected exception for request mh0bsTIbs7qY.90: java.lang.AssertionError: Batch not found in storage 5067771 > at org.teiid.common.buffer.impl.BufferManagerImpl$BatchManagerImpl.getBatch(BufferManagerImpl.java:382) > at org.teiid.common.buffer.SPage.getValues(SPage.java:234) > at org.teiid.common.buffer.SPage.search(SPage.java:135) > at org.teiid.common.buffer.STree.find(STree.java:247) > at org.teiid.common.buffer.STree.insert(STree.java:295) > at org.teiid.query.processor.relational.WindowFunctionProjectNode.saveValues(WindowFunctionProjectNode.java:419) > at org.teiid.query.processor.relational.WindowFunctionProjectNode.buildResults(WindowFunctionProjectNode.java:380) > at org.teiid.query.processor.relational.WindowFunctionProjectNode.nextBatchDirect(WindowFunctionProjectNode.java:229) > at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:277) > at org.teiid.query.processor.relational.ProjectNode.nextBatchDirect(ProjectNode.java:146) > at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:277) > at org.teiid.query.processor.relational.UnionAllNode.nextBatchDirectInternal(UnionAllNode.java:165) > at org.teiid.query.processor.relational.UnionAllNode.nextBatchDirect(UnionAllNode.java:138) > at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:277) > at org.teiid.query.processor.relational.SelectNode.nextBatchDirect(SelectNode.java:100) > at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:277) > at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:160) > at org.teiid.query.processor.relational.SourceState.prefetch(SourceState.java:207) > at org.teiid.query.processor.relational.SourceState.rowCountLE(SourceState.java:154) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4786) Report more information with max block exception

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-4786?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-4786: --------------------------------- Fix Version/s: 8.12.14.6_4 > Report more information with max block exception > ------------------------------------------------ > > Key: TEIID-4786 > URL: https://issues.jboss.org/browse/TEIID-4786 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.3, 8.12.14.6_4 > > > When the max block exception occurs in the buffer manager it reports the batch manager and batch id - but those can only be traced back to a query based upon a detail/trace log of buffer manager activity. We should provide more information, which at the very least should include the number of rows/columns, how large it actually is, column types, etc. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5362) Odata4 outputs in wrong timezone

by Debbie Steigner (JIRA)

Debbie Steigner created TEIID-5362: -------------------------------------- Summary: Odata4 outputs in wrong timezone Key: TEIID-5362 URL: https://issues.jboss.org/browse/TEIID-5362 Project: Teiid Issue Type: Bug Components: OData Affects Versions: 8.12.13.6_4 Reporter: Debbie Steigner Assignee: Steven Hawkins The incoming odata4 request is requesting the records at 08:52Z (specifying UTC time). The DataVirt server (running in US/Chicago time) converts that into SQL to ask the database for records at 03:52 (with no timezone specifier... should be in local time, or US/Chicago). The database should recognize that the 03:52 Local time should be converted back to 08:52Z to match the DB records, however, it is not. This (and other tests), leads us to the conclusion that the database session/connection is actually not using US/Chicago (-5:00) timezone, but is instead using the UTC timezone. Unfortunately, we were not able to confirm either in the logs or in the configuration, where the connection was being set up in UTC timezone. . -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5180) Execution of stored procedure with parameters failed on Teiid

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-5180?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-5180: --------------------------------- Fix Version/s: 8.12.14.6_4 > Execution of stored procedure with parameters failed on Teiid > ------------------------------------------------------------- > > Key: TEIID-5180 > URL: https://issues.jboss.org/browse/TEIID-5180 > Project: Teiid > Issue Type: Bug > Reporter: Aditi Patel > Assignee: Steven Hawkins > Fix For: 10.1, 8.12.14.6_4 > > > I have imported SAP IQ stored procedure and trying to execute the same. > > Below is the way I have imported the procedures and related views: > > {code:java} > <model name="SrcModel_5" type="PHYSICAL" visible="true"> > <property name="importer.importKeys" value="false"/> > <property name="importer.useFullSchemaName" value="true"/> > <property name="importer.UseQualifiedName" value="true" /> > <property name="importer.TableTypes" value="VIEW" /> > <property name="importer.schemapattern" value="%"/> > <property name="importer.importProcedures" value="true" /> > <source name="SrcModel_5" translator-name="sybase" connection-jndi-name="java:/dynamicST-DS-6" /> > </model> > {code} > > *Execution:* > > EXEC SrcModel_5.dwhdb.dbo.sp_iqfile() > > *Error Log:* > > {color:red}13:12:21,669 WARN [org.teiid.PROCESSOR] (Worker2_QueryProcessorQueue11) sQOZ5DwTHpU0 TEIID30020 Processing exception for request sQOZ5DwTHpU0.0 'TEIID30089 Required parameter 'SrcModel_5.dwhdb.dbo.sp_iqfile.dbspaceName' has no value was set or is an invalid parameter.'. Originally QueryResolverException ResolverUtil.java:505. Enable more detailed logging to see the entire stacktrace.{color} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3750) Allow the parsing of an expression

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-3750?page=com.atlassian.jira.plugin... ] Johnathon Lee closed TEIID-3750. -------------------------------- Resolution: Done > Allow the parsing of an expression > ---------------------------------- > > Key: TEIID-3750 > URL: https://issues.jboss.org/browse/TEIID-3750 > Project: Teiid > Issue Type: Sub-task > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.12.14.6_4, 9.0 > > > Now that we have an extension property, we could allow an expression to be used in parsing rather than just a string. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3750) Allow the parsing of an expression

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-3750?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-3750: --------------------------------- Fix Version/s: 8.12.14.6_4 > Allow the parsing of an expression > ---------------------------------- > > Key: TEIID-3750 > URL: https://issues.jboss.org/browse/TEIID-3750 > Project: Teiid > Issue Type: Sub-task > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.0, 8.12.14.6_4 > > > Now that we have an extension property, we could allow an expression to be used in parsing rather than just a string. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues June 2018