[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:
---------------------------------
Fix Version/s: 1.5.0
(was: 1.4.0)
> 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 hour
> Remaining Estimate: 4 days, 7 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, 10 months
[JBoss JIRA] (TEIID-5838) Add a vdb/source metadata load timeout
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIID-5838?page=com.atlassian.jira.plugi... ]
Steven Hawkins updated TEIID-5838:
----------------------------------
Summary: Add a vdb/source metadata load timeout (was: Add a vdb load timeout)
It would probably be easier to think about enforcing this on each source load, rather than across the entire vdb load.
> Add a vdb/source metadata load timeout
> --------------------------------------
>
> Key: TEIID-5838
> URL: https://issues.redhat.com/browse/TEIID-5838
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Minor
> Fix For: 14.0
>
>
> Source vdb loads should timeout to prevent refresh and other issues.
> Note: this may be implemented in core Teiid, in which case this issue will be moved.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (TEIID-4691) Consider replacing JGroups based custom replication with native
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIID-4691?page=com.atlassian.jira.plugi... ]
Steven Hawkins resolved TEIID-4691.
-----------------------------------
Fix Version/s: (was: 13.x)
Resolution: Out of Date
Teiid WildFly will remain on JGroups for the forseeable future. Teiid Spring Boot will move toward an alternative eventing / replication mechanism.
> Consider replacing JGroups based custom replication with native
> ---------------------------------------------------------------
>
> Key: TEIID-4691
> URL: https://issues.redhat.com/browse/TEIID-4691
> Project: Teiid
> Issue Type: Enhancement
> Components: Server
> Reporter: Ramesh Reddy
> Priority: Major
>
> JGroups is responsible for node to node communication. JGroups FRAG2 chunks up the messages that are sizeable by flow control. If you use TCP it will automatically break up the messages into the MTU. Using Jumbo Frames would be recommended.
> Note that this will affect how we do the materialization replication among nodes currently.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (TEIID-5844) Schema level permissions are not checked proactively for foreign temporary tables
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIID-5844?page=com.atlassian.jira.plugi... ]
Steven Hawkins updated TEIID-5844:
----------------------------------
Fix Version/s: 14.0
(was: 13.x)
> Schema level permissions are not checked proactively for foreign temporary tables
> ---------------------------------------------------------------------------------
>
> Key: TEIID-5844
> URL: https://issues.redhat.com/browse/TEIID-5844
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Minor
> Fix For: 14.0
>
>
> Anyone with the permission to create a temporary table can create a foreign temporary table. From there we'll check the permissions on operations against the schema. It would be nice to error out on the create temporary table if the user is not going to be sufficient permissioned to use it. It's currently not the case, but if we ever have source level side effects from create foreign temp, then it becomes important to prevent the create as well.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (TEIID-4558) Query Plan Analyzer
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIID-4558?page=com.atlassian.jira.plugi... ]
Steven Hawkins commented on TEIID-4558:
---------------------------------------
To recap, there are a couple of things touched on here:
* static analysis of a query plan, which would indicate things like table access without predicates, cross joins etc. -- all of that information is in the simple plan. Additionally you could scan the debug log for annotations related to pushdown to highlight what predicates aren't pushed and why.
* analysis of a plan after it's been run, which looks more like a profiling tool to indicate what is the slowest part of the plan, etc. This information as well is currently all in the simple plan.
Either way this really becomes about the user experience of consuming existing information, so I'm moving this over to Teiid Tools.
> Query Plan Analyzer
> -------------------
>
> Key: TEIID-4558
> URL: https://issues.redhat.com/browse/TEIID-4558
> Project: Teiid
> Issue Type: Feature Request
> Components: Tools
> Reporter: Van Halbert
> Priority: Major
>
> Provide a tool that would take a query plan and provide feed back.
> Example:
> - indicate where there maybe a problem in the structure of the query that may impact performance
> - indicate in the plan where there maybe issues (like table scan, no rows, etc.)
> - provide recommendations for improving performance
> etc..
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (TEIID-4030) Improve Geometry Type Handling in HANA Translator
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIID-4030?page=com.atlassian.jira.plugi... ]
Steven Hawkins updated TEIID-4030:
----------------------------------
Fix Version/s: Open To Community
This boils down to adding the methods:
translateGeo*Select
retrieveGeo*Value
So that we can appropriately pushdown literal/bindings and retrieve values.
> Improve Geometry Type Handling in HANA Translator
> -------------------------------------------------
>
> Key: TEIID-4030
> URL: https://issues.redhat.com/browse/TEIID-4030
> Project: Teiid
> Issue Type: Feature Request
> Components: Misc. Connectors
> Affects Versions: 8.13.1
> Reporter: Edwin Jones
> Priority: Major
> Fix For: 13.x, Open To Community
>
>
> The Geometry type logic in the HANA translator should use the new Teiid Geometry type, similar to the postgres translator.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (TEIID-3298) invokeHttp procedure should support returning HTTP Response Code
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIID-3298?page=com.atlassian.jira.plugi... ]
Steven Hawkins resolved TEIID-3298.
-----------------------------------
Fix Version/s: (was: 13.x)
Resolution: Out of Date
Marking as out of date as there's been no movement on this. All of the paths that use the return code have direct access to the execution. Given the way the procedure logic works, this would require a new output parameter and/or a new invoke call.
> invokeHttp procedure should support returning HTTP Response Code
> ----------------------------------------------------------------
>
> Key: TEIID-3298
> URL: https://issues.redhat.com/browse/TEIID-3298
> Project: Teiid
> Issue Type: Enhancement
> Components: Misc. Connectors
> Affects Versions: 8.4
> Reporter: Ramesh Reddy
> Priority: Major
>
> Currently WS Translator supplied "invokeHttp" procedure only returns the result and as well as the content-type. It should also return response code.
> It may be useful to check if there is any other return parameters can be useful too. Like cookie etc.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months