[JBoss JIRA] (TEIID-5852) views are resolved twice in the metadata validator
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIID-5852?page=com.atlassian.jira.plugi... ]
Steven Hawkins edited comment on TEIID-5852 at 2/28/20 12:56 PM:
-----------------------------------------------------------------
The purpose of the dual resolving is to first resolve just the query command, then to resolve view after adjustments have been made to the metadata. The re-resolving makes it easier to avoid corner cases with the metadata adjustments. Unless we move the knowledge of that up into the metadata validation, then we should just leave this as is for now.
was (Author: shawkins):
The purpose of the dual resolving is to first resolve just the query command, then to resolve view after adjustments have been made to the metadata. I wasn't successful even with skipping just the reparsing of the sql, let alone the re-resolving as there are corner cases about each situation. Unless we move the knowledge of that up into the metadata validation, then we should just leave this as is for now.
> views are resolved twice in the metadata validator
> --------------------------------------------------
>
> Key: TEIID-5852
> URL: https://issues.redhat.com/browse/TEIID-5852
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 13.1
>
>
> There is an initial resolve to run the Validation visitor, then another resolve in resolveView. This should be combined as much as possible.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 9 months
[JBoss JIRA] (TEIID-5852) views are resolved twice in the metadata validator
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIID-5852?page=com.atlassian.jira.plugi... ]
Steven Hawkins resolved TEIID-5852.
-----------------------------------
Resolution: Rejected
The purpose of the dual resolving is to first resolve just the query command, then to resolve view after adjustments have been made to the metadata. I wasn't successful even with skipping just the reparsing of the sql, let alone the re-resolving as there are corner cases about each situation. Unless we move the knowledge of that up into the metadata validation, then we should just leave this as is for now.
> views are resolved twice in the metadata validator
> --------------------------------------------------
>
> Key: TEIID-5852
> URL: https://issues.redhat.com/browse/TEIID-5852
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 13.1
>
>
> There is an initial resolve to run the Validation visitor, then another resolve in resolveView. This should be combined as much as possible.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 9 months
[JBoss JIRA] (TEIID-5866) Teiid embedded does not implement active vdb import management
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIID-5866?page=com.atlassian.jira.plugi... ]
Work on TEIID-5866 started by Steven Hawkins.
---------------------------------------------
> Teiid embedded does not implement active vdb import management
> --------------------------------------------------------------
>
> Key: TEIID-5866
> URL: https://issues.redhat.com/browse/TEIID-5866
> Project: Teiid
> Issue Type: Quality Risk
> Components: Embedded
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 13.1
>
>
> This should initially be resolved by calling out the difference in handling in the docs. In short when you use vdb imports in embedded the import is processed at deployment time only. If the imported vdb later changes, it will cause any changes in importing vdbs.
> Note that in teiid-syndesis this import management logic was added via a custom vdb lifecycle listener, but that isn't quite the best solution given that we shouldn't be doing a lot of work in that thread.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 9 months
[JBoss JIRA] (TEIID-5751) Please add optimization support for foreign keys in materialized tables
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIID-5751?page=com.atlassian.jira.plugi... ]
Steven Hawkins updated TEIID-5751:
----------------------------------
Story Points: 0.5
Sprint: DV Sprint 60
> Please add optimization support for foreign keys in materialized tables
> -----------------------------------------------------------------------
>
> Key: TEIID-5751
> URL: https://issues.redhat.com/browse/TEIID-5751
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Affects Versions: 12.2
> Reporter: Christoph John
> Assignee: Steven Hawkins
> Priority: Minor
> Fix For: 13.1
>
>
> The issues came up in the following discussion
> https://developer.jboss.org/message/989502#989502
> > 1a) Are the constraints (indexes, foreign keys) now used to optimize queries in materialized tables or not?
>
> Pk, Unique Key, and Indexes on the view will result in the creation of an index on the materialization target table and are fully utilized in planning decisions. Things are a little more complicated with foreign keys. {color:red}Currently they are not propagated onto the generated materialization target table metadata, so they are only considered in pre-planner activities, such as rewrite, before the view reference is replaced with the materialization target - but there aren't meaningful optimizations being made at that time based upon foreign key. There are couple of narrow situations where that information would be useful{color}, so it probably should be added.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 9 months