March 2019 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-5648) More consistency in how metadata is hidden or not

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5648?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5648. ----------------------------------- Resolution: Done Added the system/environment property org.teiid.metadataRequiresPermission which default to true. If false the DefaultAuthorizationVisitor will allow all objects to be visible without any permissions. This change also incorporates the logic to have visibility to tables/procedures for alternative permissions such as alter, create, update, delete. > More consistency in how metadata is hidden or not > ------------------------------------------------- > > Key: TEIID-5648 > URL: https://issues.jboss.org/browse/TEIID-5648 > Project: Teiid > Issue Type: Quality Risk > Components: JDBC Driver, OData, ODBC > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.2 > > > All schemas, not marked as hidden, will be visible over odata. This includes all schema objects. Via the other access mechanisms permission is now required for visibility - TEIID-5516 and TEIID-2476. > We should offer more consistency, such as an option to still expose the metadata by default for non-odata access even if the user is not permissioned. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5648) More consistency in how metadata is hidden or not

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5648?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-5648: ---------------------------------- Component/s: JDBC Driver ODBC Description: All schemas, not marked as hidden, will be visible over odata. This includes all schema objects. Via the other access mechanisms permission is now required for visibility - TEIID-5516 and TEIID-2476. We should offer more consistency, such as an option to still expose the metadata by default for non-odata access even if the user is not permissioned. was: All schemas, not marked as hidden, will be visible over odata. This includes all schema objects. Via the other access mechanisms permission is now required for visibility - TEIID-5516 and TEIID-2476. Alternatively there could also be an option to still expose the metadata by default for non-odata access even if the user is not permissioned. Summary: More consistency in how metadata is hidden or not (was: Hide metadata over odata) > More consistency in how metadata is hidden or not > ------------------------------------------------- > > Key: TEIID-5648 > URL: https://issues.jboss.org/browse/TEIID-5648 > Project: Teiid > Issue Type: Quality Risk > Components: JDBC Driver, OData, ODBC > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.2 > > > All schemas, not marked as hidden, will be visible over odata. This includes all schema objects. Via the other access mechanisms permission is now required for visibility - TEIID-5516 and TEIID-2476. > We should offer more consistency, such as an option to still expose the metadata by default for non-odata access even if the user is not permissioned. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5701) Add settings.xml to the openshfit-examples

by Van Halbert (Jira)

[ https://issues.jboss.org/browse/TEIID-5701?page=com.atlassian.jira.plugin... ] Work on TEIID-5701 started by Van Halbert. ------------------------------------------ > Add settings.xml to the openshfit-examples > ------------------------------------------ > > Key: TEIID-5701 > URL: https://issues.jboss.org/browse/TEIID-5701 > Project: Teiid > Issue Type: Task > Components: Build/Kits, Quick Starts > Reporter: Van Halbert > Assignee: Van Halbert > Priority: Major > > With DV being released in tech-preview and the artifacts will be released in the earlyaccess MRRC repo, there needs to be a settings.xml file that has the MRRC earlyaccess and ga repos configured. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5701) Add settings.xml to the openshfit-examples

by Van Halbert (Jira)

Van Halbert created TEIID-5701: ---------------------------------- Summary: Add settings.xml to the openshfit-examples Key: TEIID-5701 URL: https://issues.jboss.org/browse/TEIID-5701 Project: Teiid Issue Type: Task Components: Build/Kits, Quick Starts Reporter: Van Halbert Assignee: Van Halbert With DV being released in tech-preview and the artifacts will be released in the earlyaccess MRRC repo, there needs to be a settings.xml file that has the MRRC earlyaccess and ga repos configured. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5680) Improve performance of odata expand operations

by Christoph John (Jira)

[ https://issues.jboss.org/browse/TEIID-5680?page=com.atlassian.jira.plugin... ] Christoph John commented on TEIID-5680: --------------------------------------- Hello Steven, the workaround does the job. Thanks a lot ! > Improve performance of odata expand operations > ---------------------------------------------- > > Key: TEIID-5680 > URL: https://issues.jboss.org/browse/TEIID-5680 > Project: Teiid > Issue Type: Enhancement > Components: OData > Reporter: Christoph John > Assignee: Steven Hawkins > Priority: Major > Attachments: logfile.txt, svc-vdb.xml, test2.txt > > > Hello Ramesh and Steven, > this is a follow up regarding an observation in the discussion from TEIID-5643. I thought I open an extra issue for the topic as this seems not to be related to TEIID-5500. > As you already know, I am using SAPUI5 as frontend for ODATA requests. SAPUI5 supports binding of a user interface control group (like a list with its list items) to a single ODATA path at a time only. If the control group items require additional information which is stored in a different table in the database, I have to expand those parameters in the odata query. > When doing so, I am running in a serious performance issue with TEIID, which would render the approach of using sapui5 with Teiid infeasible if we cannot find a way to speedup the issue. At the moment I have a small table with entries (table Diary with about 20 records) for which the query extracts several items (just a single one in the example given below). Now the filtered item is expanded with data from a larger table in the database (FDBProducts with about 680.000 records). The whole query takes about 15s to be processed. The query is given as: > https://morpheus.fritz.box/odata4/svc/my_nutri_diary/Diary?$select=Amount... > I checked the output when using > <logger category="org.teiid.CONNECTOR"><level name="TRACE"/></logger> > This shows the problem. It seems the join operation is not pushed down to the database but the data are rather joined within Teiid. Teiid therefore downloads the entire dataset of the large FDBProducts table, which makes the expand approach infeasible for real world datasets with a certain size. So my question is, if you can modify Teiid to push down the entire join operation to the underlaying database (I assume this would be the most efficient approach), or alternatively query just the items from the table to be joined which where filtered from the first table if the first option is not possible? > Thanks for your help. > Christoph -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5680) Improve performance of odata expand operations

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5680?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5680: --------------------------------------- [~cjohn001] see TEIID-5700. A workaround is to set the diary cardinality value higher. > Improve performance of odata expand operations > ---------------------------------------------- > > Key: TEIID-5680 > URL: https://issues.jboss.org/browse/TEIID-5680 > Project: Teiid > Issue Type: Enhancement > Components: OData > Reporter: Christoph John > Assignee: Steven Hawkins > Priority: Major > Attachments: logfile.txt, svc-vdb.xml, test2.txt > > > Hello Ramesh and Steven, > this is a follow up regarding an observation in the discussion from TEIID-5643. I thought I open an extra issue for the topic as this seems not to be related to TEIID-5500. > As you already know, I am using SAPUI5 as frontend for ODATA requests. SAPUI5 supports binding of a user interface control group (like a list with its list items) to a single ODATA path at a time only. If the control group items require additional information which is stored in a different table in the database, I have to expand those parameters in the odata query. > When doing so, I am running in a serious performance issue with TEIID, which would render the approach of using sapui5 with Teiid infeasible if we cannot find a way to speedup the issue. At the moment I have a small table with entries (table Diary with about 20 records) for which the query extracts several items (just a single one in the example given below). Now the filtered item is expanded with data from a larger table in the database (FDBProducts with about 680.000 records). The whole query takes about 15s to be processed. The query is given as: > https://morpheus.fritz.box/odata4/svc/my_nutri_diary/Diary?$select=Amount... > I checked the output when using > <logger category="org.teiid.CONNECTOR"><level name="TRACE"/></logger> > This shows the problem. It seems the join operation is not pushed down to the database but the data are rather joined within Teiid. Teiid therefore downloads the entire dataset of the large FDBProducts table, which makes the expand approach infeasible for real world datasets with a certain size. So my question is, if you can modify Teiid to push down the entire join operation to the underlaying database (I assume this would be the most efficient approach), or alternatively query just the items from the table to be joined which where filtered from the first table if the first option is not possible? > Thanks for your help. > Christoph -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5700) Dependent join back-off max ndv set to independent ndv estimate

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5700?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-5700: ---------------------------------- Workaround Description: Set the cardinality value of the independent side table(s) to a higher value to allow the dependent join to proceed. > Dependent join back-off max ndv set to independent ndv estimate > --------------------------------------------------------------- > > Key: TEIID-5700 > URL: https://issues.jboss.org/browse/TEIID-5700 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.2, 11.2.3, 12.1.1 > > > The search being used to find a max ndv for the independent side is just setting the result to be the original ndv estimate for the independent side. This results in unnecessary back-offs of performing the dependent join with a log message similar to: > TEIID30011 Not performing dependent join using source $dsc/id0, since the number of distinct rows for expression g0.fkIdProductCode exceeds 1.333. You should ensure that your source statistics, including column distinct value counts, accurately reflect the source or use a MAKE_DEP hint to force the join. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5700) Dependent join back-off max ndv set to independent ndv estimate

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5700?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-5700: ---------------------------------- Description: The search being used to find a max ndv for the independent side is just setting the result to be the original ndv estimate for the independent side. This results in unnecessary back-offs of performing the dependent join with a log message similar to: TEIID30011 Not performing dependent join using source $dsc/id0, since the number of distinct rows for expression g0.fkIdProductCode exceeds 1.333. You should ensure that your source statistics, including column distinct value counts, accurately reflect the source or use a MAKE_DEP hint to force the join. was:The search being used to find a max ndv for the independent side is just setting the result to be the original ndv estimate for the independent side. This results in unnecessary back-offs of performing the dependent join. > Dependent join back-off max ndv set to independent ndv estimate > --------------------------------------------------------------- > > Key: TEIID-5700 > URL: https://issues.jboss.org/browse/TEIID-5700 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.2, 11.2.3, 12.1.1 > > > The search being used to find a max ndv for the independent side is just setting the result to be the original ndv estimate for the independent side. This results in unnecessary back-offs of performing the dependent join with a log message similar to: > TEIID30011 Not performing dependent join using source $dsc/id0, since the number of distinct rows for expression g0.fkIdProductCode exceeds 1.333. You should ensure that your source statistics, including column distinct value counts, accurately reflect the source or use a MAKE_DEP hint to force the join. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5700) Dependent join back-off max ndv set to independent ndv estimate

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5700?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5700. ----------------------------------- Resolution: Done The dependent join back-off calculation was updated to use the ndv value calculated based upon the quick search. This will generally be much higher than the previous value which was just the independent value ndv. > Dependent join back-off max ndv set to independent ndv estimate > --------------------------------------------------------------- > > Key: TEIID-5700 > URL: https://issues.jboss.org/browse/TEIID-5700 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.2, 11.2.3, 12.1.1 > > > The search being used to find a max ndv for the independent side is just setting the result to be the original ndv estimate for the independent side. This results in unnecessary back-offs of performing the dependent join. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5700) Dependent join back-off max ndv set to independent ndv estimate

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5700?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-5700: ---------------------------------- Fix Version/s: 12.2 11.2.3 12.1.1 > Dependent join back-off max ndv set to independent ndv estimate > --------------------------------------------------------------- > > Key: TEIID-5700 > URL: https://issues.jboss.org/browse/TEIID-5700 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.2, 11.2.3, 12.1.1 > > > The search being used to find a max ndv for the independent side is just setting the result to be the original ndv estimate for the independent side. This results in unnecessary back-offs of performing the dependent join. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues March 2019