April 2020 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-5946) condition support for masks needs restored

by Steven Hawkins (Jira)

Steven Hawkins created TEIID-5946: ------------------------------------- Summary: condition support for masks needs restored Key: TEIID-5946 URL: https://issues.redhat.com/browse/TEIID-5946 Project: Teiid Issue Type: Bug Components: Query Engine Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 14.0, 13.1.1 Cleanup in TEIID-4770 TEIID-4771 removed the ability to set a condition with a mask - more than likely to avoid specifying whether the condition was a constraint. That should be added back. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5940) How to connect GCP bucket using Teiid

by Nayan Bijagare (Jira)

[ https://issues.redhat.com/browse/TEIID-5940?page=com.atlassian.jira.plugi... ] Nayan Bijagare commented on TEIID-5940: --------------------------------------- Hi Steven. Thanks for the reply, Could you please tell us, up to when this issue gets resolved on Teiid? > How to connect GCP bucket using Teiid > ------------------------------------- > > Key: TEIID-5940 > URL: https://issues.redhat.com/browse/TEIID-5940 > Project: Teiid > Issue Type: Feature Request > Components: JDBC Connector > Reporter: nayan Bijagare > Assignee: Steven Hawkins > Priority: Major > Labels: GCP_BUC, jdbc-connector, team-service-2 > Original Estimate: 3 days > Remaining Estimate: 3 days > > We need to read flat file or CSV file tabular data using Teiid. > We couldn't find any JDBC driver by using it we can establish the connection with the GCP Bucket. > Could you please suggest us any solution how to connect to GCP bucket using Teiid. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-157) Support loading password credential from infinispan secret

by Ramesh Reddy (Jira)

[ https://issues.redhat.com/browse/TEIIDSB-157?page=com.atlassian.jira.plug... ] Ramesh Reddy resolved TEIIDSB-157. ---------------------------------- Resolution: Won't Fix This is more tied with Infinispan, and we should not use this secret as automation is not cleanly possible if we try to reuse Infinispan's secret. > Support loading password credential from infinispan secret > ---------------------------------------------------------- > > Key: TEIIDSB-157 > URL: https://issues.redhat.com/browse/TEIIDSB-157 > Project: Teiid Spring Boot > Issue Type: Enhancement > Components: datasource > Reporter: Steven Hawkins > Priority: Major > Fix For: 1.5.0 > > Original Estimate: 5 hours > Time Spent: 2 hours > Remaining Estimate: 3 hours > > The infinispan operator generates a secret that contains a yaml file, which is where the developer password is stored. > There three approaches: > 1. for materialization assume that we will "own" the DataGrid instance such that we'll create and pass our own secret file for infinispan to use. In this case we'll know the password and can provide that to the connection factory via an env property. > 2. add logic to the connection factory to specify a "credential file" such that we'll parse the yaml from the given location (a mount of the secret) and find the appropriate credential for the given username (typically developer). > 3. ask the infinispan team to allow for easier consumption of the secret (a secret per user?) > To get things working with the example, I can take the first approach - but it will look a little convoluted. > In general 2 or 3 will be needed in scenarios where we expect to simply pick up existing credentials. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-192) Document migration for alias names

by Ramesh Reddy (Jira)

[ https://issues.redhat.com/browse/TEIIDSB-192?page=com.atlassian.jira.plug... ] Ramesh Reddy updated TEIIDSB-192: --------------------------------- Story Points: 1 > Document migration for alias names > ---------------------------------- > > Key: TEIIDSB-192 > URL: https://issues.redhat.com/browse/TEIIDSB-192 > Project: Teiid Spring Boot > Issue Type: Task > Components: documentation > Reporter: Ramesh Reddy > Priority: Major > Fix For: 1.5.0 > > > Translators like salesforce and actian-vector has new name in the spring boot, we need to either document or switch back to original names. > Also if we are updating migration utilities we can build in smarts into it. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-170) Automate materialization to JDG

by Ramesh Reddy (Jira)

[ https://issues.redhat.com/browse/TEIIDSB-170?focusedWorklogId=12450914&pa... ] Ramesh Reddy logged work on TEIIDSB-170: ---------------------------------------- Author: Ramesh Reddy Created on: 29/Apr/20 6:58 PM Start Date: 29/Apr/20 6:57 PM Worklog Time Spent: 1 day, 7 hours Work Description: more time on Operator and setting up a infinispan private cluster which is not included in the original design Issue Time Tracking ------------------- Remaining Estimate: 0 minutes (was: 5 hours) Time Spent: 1 week, 1 day, 2 hours (was: 4 days, 3 hours) Worklog Id: (was: 12450914) > Automate materialization to JDG > ------------------------------- > > Key: TEIIDSB-170 > URL: https://issues.redhat.com/browse/TEIIDSB-170 > Project: Teiid Spring Boot > Issue Type: Enhancement > Components: OpenShift > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Priority: Major > Fix For: 1.5.0 > > Original Estimate: 1 week > Time Spent: 1 week, 1 day, 2 hours > Remaining Estimate: 0 minutes > > Create an internal materialization replacement needs that is turnkey materialization to JDG (little to no user setup required) > - the operator may create the infinispan cluster if needed > - the status table and internal representation of the materialization target would be setup automatically > For the user this would be as simple marking a view as materialized and then it would be populated in jdg upon deployment. They would not have any concerns with cache naming, status tables, etc. > For simplicity the initial version would make a similar assumption to the current internal logic - it is for only a specific vdb. If the vdb cr is modified, then it's expected that the cache would be recreated. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5945) queries with SUM(big integer) throw NPE

by Steven Hawkins (Jira)

[ https://issues.redhat.com/browse/TEIID-5945?page=com.atlassian.jira.plugi... ] Steven Hawkins updated TEIID-5945: ---------------------------------- Fix Version/s: 14.0 13.0.3 13.1.1 Original Estimate: 4 hours Remaining Estimate: 4 hours Story Points: 0.5 Sprint: DV Sprint 63 Summary: queries with SUM(big integer) throw NPE (was: queries with SUM(big integer) throw NPE (amazon athena)) Priority: Critical (was: Major) > queries with SUM(big integer) throw NPE > --------------------------------------- > > Key: TEIID-5945 > URL: https://issues.redhat.com/browse/TEIID-5945 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Critical > Fix For: 14.0, 13.0.3, 13.1.1 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > Both queries: > {code:java} > SELECT A.INTKEY, A.BIGINTEGERVALUE, (SELECT SUM(B.BIGINTEGERVALUE) FROM bqt.SMALLA AS B WHERE B.INTKEY = A.INTKEY) FROM bqt.SMALLA AS A; > SELECT INTKEY, BIGINTEGERVALUE FROM bqt.SMALLA AS A WHERE BIGINTEGERVALUE >= (SELECT SUM(BIGINTEGERVALUE) FROM bqt.SMALLA AS B WHERE A.INTKEY = B.INTKEY); > {code} > throw NPE when they are run against amazon athena vdb. > The same queries return the right data when they are run against amazon athena directly. > Attached stacktrace points that the problem is in SUM(big integer). > A similar query with SUM(long) works fine. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5945) queries with SUM(big integer) throw NPE

by Steven Hawkins (Jira)

[ https://issues.redhat.com/browse/TEIID-5945?page=com.atlassian.jira.plugi... ] Steven Hawkins resolved TEIID-5945. ----------------------------------- Resolution: Done There was an asymmetry with the sum set state code where the isnull flag was not set for bigdecimal/integer. > queries with SUM(big integer) throw NPE > --------------------------------------- > > Key: TEIID-5945 > URL: https://issues.redhat.com/browse/TEIID-5945 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Critical > Fix For: 14.0, 13.0.3, 13.1.1 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > Both queries: > {code:java} > SELECT A.INTKEY, A.BIGINTEGERVALUE, (SELECT SUM(B.BIGINTEGERVALUE) FROM bqt.SMALLA AS B WHERE B.INTKEY = A.INTKEY) FROM bqt.SMALLA AS A; > SELECT INTKEY, BIGINTEGERVALUE FROM bqt.SMALLA AS A WHERE BIGINTEGERVALUE >= (SELECT SUM(BIGINTEGERVALUE) FROM bqt.SMALLA AS B WHERE A.INTKEY = B.INTKEY); > {code} > throw NPE when they are run against amazon athena vdb. > The same queries return the right data when they are run against amazon athena directly. > Attached stacktrace points that the problem is in SUM(big integer). > A similar query with SUM(long) works fine. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5945) queries with SUM(big integer) throw NPE

by Steven Hawkins (Jira)

[ https://issues.redhat.com/browse/TEIID-5945?focusedWorklogId=12450913&pag... ] Steven Hawkins logged work on TEIID-5945: ----------------------------------------- Author: Steven Hawkins Created on: 29/Apr/20 4:17 PM Start Date: 29/Apr/20 4:16 PM Worklog Time Spent: 4 hours Work Description: It took a while to create a simple processor test case to reproduce this. Issue Time Tracking ------------------- Remaining Estimate: 0 minutes (was: 4 hours) Time Spent: 4 hours Worklog Id: (was: 12450913) > queries with SUM(big integer) throw NPE > --------------------------------------- > > Key: TEIID-5945 > URL: https://issues.redhat.com/browse/TEIID-5945 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Critical > Fix For: 14.0, 13.0.3, 13.1.1 > > Original Estimate: 4 hours > Time Spent: 4 hours > Remaining Estimate: 0 minutes > > Both queries: > {code:java} > SELECT A.INTKEY, A.BIGINTEGERVALUE, (SELECT SUM(B.BIGINTEGERVALUE) FROM bqt.SMALLA AS B WHERE B.INTKEY = A.INTKEY) FROM bqt.SMALLA AS A; > SELECT INTKEY, BIGINTEGERVALUE FROM bqt.SMALLA AS A WHERE BIGINTEGERVALUE >= (SELECT SUM(BIGINTEGERVALUE) FROM bqt.SMALLA AS B WHERE A.INTKEY = B.INTKEY); > {code} > throw NPE when they are run against amazon athena vdb. > The same queries return the right data when they are run against amazon athena directly. > Attached stacktrace points that the problem is in SUM(big integer). > A similar query with SUM(long) works fine. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-170) Automate materialization to JDG

by Ramesh Reddy (Jira)

[ https://issues.redhat.com/browse/TEIIDSB-170?page=com.atlassian.jira.plug... ] Ramesh Reddy commented on TEIIDSB-170: -------------------------------------- Where caches in Infinispan can be managed as Custom Resources. Teiid would need this to manage caches when working with shared clusters https://github.com/infinispan/infinispan-operator/issues/356 Using a REST API https://infinispan.org/docs/dev/titles/rest/rest.html#rest_v2_remove_cache However, in Openshift there is no route created to reach the HTTP endpoint > Automate materialization to JDG > ------------------------------- > > Key: TEIIDSB-170 > URL: https://issues.redhat.com/browse/TEIIDSB-170 > Project: Teiid Spring Boot > Issue Type: Enhancement > Components: OpenShift > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Priority: Major > Fix For: 1.5.0 > > Original Estimate: 1 week > Time Spent: 4 days, 3 hours > Remaining Estimate: 5 hours > > Create an internal materialization replacement needs that is turnkey materialization to JDG (little to no user setup required) > - the operator may create the infinispan cluster if needed > - the status table and internal representation of the materialization target would be setup automatically > For the user this would be as simple marking a view as materialized and then it would be populated in jdg upon deployment. They would not have any concerns with cache naming, status tables, etc. > For simplicity the initial version would make a similar assumption to the current internal logic - it is for only a specific vdb. If the vdb cr is modified, then it's expected that the cache would be recreated. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5945) queries with SUM(big integer) throw NPE (amazon athena)

by Steven Hawkins (Jira)

[ https://issues.redhat.com/browse/TEIID-5945?page=com.atlassian.jira.plugi... ] Steven Hawkins moved ENTESB-13658 to TEIID-5945: ------------------------------------------------ Project: Teiid (was: Red Hat Fuse) Key: TEIID-5945 (was: ENTESB-13658) Workflow: classic default workflow (was: ENTESB Planned Work) Component/s: Query Engine (was: Data Integration) Target Release: (was: fuse-next-GA) > queries with SUM(big integer) throw NPE (amazon athena) > ------------------------------------------------------- > > Key: TEIID-5945 > URL: https://issues.redhat.com/browse/TEIID-5945 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > > Both queries: > {code:java} > SELECT A.INTKEY, A.BIGINTEGERVALUE, (SELECT SUM(B.BIGINTEGERVALUE) FROM bqt.SMALLA AS B WHERE B.INTKEY = A.INTKEY) FROM bqt.SMALLA AS A; > SELECT INTKEY, BIGINTEGERVALUE FROM bqt.SMALLA AS A WHERE BIGINTEGERVALUE >= (SELECT SUM(BIGINTEGERVALUE) FROM bqt.SMALLA AS B WHERE A.INTKEY = B.INTKEY); > {code} > throw NPE when they are run against amazon athena vdb. > The same queries return the right data when they are run against amazon athena directly. > Attached stacktrace points that the problem is in SUM(big integer). > A similar query with SUM(long) works fine. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues April 2020