[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
[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
[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
[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
[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
[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
[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
[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
[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