[JBoss JIRA] (TEIID-5909) Pg compatibility issues to support Graphback API
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIID-5909?page=com.atlassian.jira.plugi... ]
Steven Hawkins commented on TEIID-5909:
---------------------------------------
Opened a pr with the change described above. [~rareddy] did you see any particular issue with the charset handling?
> Pg compatibility issues to support Graphback API
> ------------------------------------------------
>
> Key: TEIID-5909
> URL: https://issues.redhat.com/browse/TEIID-5909
> Project: Teiid
> Issue Type: Enhancement
> Components: ODBC
> Reporter: Ramesh Reddy
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 13.1
>
> Time Spent: 2 hours
> Remaining Estimate: 0 minutes
>
> 1) Graphback expects "select version()" call to return the result set with alias "version" as column name
> 2) The client supplies the "utf-8" as the charset, which needs to be treated as UTF-8
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (TEIID-5912) DatabaseUtil should not make assumptions about resource types
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIID-5912?focusedWorklogId=12450310&pag... ]
Steven Hawkins logged work on TEIID-5912:
-----------------------------------------
Author: Steven Hawkins
Created on: 24/Feb/20 5:14 PM
Start Date: 24/Feb/20 5:13 PM
Worklog Time Spent: 2 hours, 30 minutes
Issue Time Tracking
-------------------
Remaining Estimate: 0 minutes (was: 2 hours)
Time Spent: 2 hours, 30 minutes
Worklog Id: (was: 12450310)
> DatabaseUtil should not make assumptions about resource types
> -------------------------------------------------------------
>
> Key: TEIID-5912
> URL: https://issues.redhat.com/browse/TEIID-5912
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 13.1, 13.0.3
>
> Original Estimate: 2 hours
> Time Spent: 2 hours, 30 minutes
> Remaining Estimate: 0 minutes
>
> DatabaseUtil is making assumptions about the resource type based upon the name alone, which is not necessarily correct. Rather than potentially making an incorrect assumption, we should create invalid ddl that the user must then correct.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (TEIID-5912) DatabaseUtil should not make assumptions about resource types
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIID-5912?page=com.atlassian.jira.plugi... ]
Steven Hawkins updated TEIID-5912:
----------------------------------
Original Estimate: 2 hours
Remaining Estimate: 2 hours
> DatabaseUtil should not make assumptions about resource types
> -------------------------------------------------------------
>
> Key: TEIID-5912
> URL: https://issues.redhat.com/browse/TEIID-5912
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 13.1, 13.0.3
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> DatabaseUtil is making assumptions about the resource type based upon the name alone, which is not necessarily correct. Rather than potentially making an incorrect assumption, we should create invalid ddl that the user must then correct.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (TEIID-5912) DatabaseUtil should not make assumptions about resource types
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIID-5912?page=com.atlassian.jira.plugi... ]
Steven Hawkins resolved TEIID-5912.
-----------------------------------
Resolution: Done
Used the metadata if available - which is currently only for a wildfly deployed vdb, and not for the convert utility - to better determine the type. If it's ambiguous or unknown, we'll emit invalid ddl.
> DatabaseUtil should not make assumptions about resource types
> -------------------------------------------------------------
>
> Key: TEIID-5912
> URL: https://issues.redhat.com/browse/TEIID-5912
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 13.1, 13.0.3
>
>
> DatabaseUtil is making assumptions about the resource type based upon the name alone, which is not necessarily correct. Rather than potentially making an incorrect assumption, we should create invalid ddl that the user must then correct.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (TEIID-5912) DatabaseUtil should not make assumptions about resource types
by Steven Hawkins (Jira)
Steven Hawkins created TEIID-5912:
-------------------------------------
Summary: DatabaseUtil should not make assumptions about resource types
Key: TEIID-5912
URL: https://issues.redhat.com/browse/TEIID-5912
Project: Teiid
Issue Type: Quality Risk
Components: Query Engine
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 13.1, 13.0.3
DatabaseUtil is making assumptions about the resource type based upon the name alone, which is not necessarily correct. Rather than potentially making an incorrect assumption, we should create invalid ddl that the user must then correct.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[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 updated TEIIDSB-157:
---------------------------------
Sprint: DV Sprint 60
> 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.4.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, 10 months
[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 updated TEIIDSB-170:
---------------------------------
Sprint: DV Sprint 60
> 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.4.0
>
>
> 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, 10 months
[JBoss JIRA] (TEIID-5909) Pg compatibility issues to support Graphback API
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIID-5909?page=com.atlassian.jira.plugi... ]
Steven Hawkins commented on TEIID-5909:
---------------------------------------
Based upon the pr review the new direction will be to use some kind of optional behavior for pg queries to mimic the aliasing / column naming of pg. This would be similar to how the pg interface turns on positional order by support.
> Pg compatibility issues to support Graphback API
> ------------------------------------------------
>
> Key: TEIID-5909
> URL: https://issues.redhat.com/browse/TEIID-5909
> Project: Teiid
> Issue Type: Enhancement
> Components: ODBC
> Reporter: Ramesh Reddy
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 13.1
>
> Time Spent: 2 hours
> Remaining Estimate: 0 minutes
>
> 1) Graphback expects "select version()" call to return the result set with alias "version" as column name
> 2) The client supplies the "utf-8" as the charset, which needs to be treated as UTF-8
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months