March 2019 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-5648) Hide metadata over odata

by Ramesh Reddy (Jira)

[ https://issues.jboss.org/browse/TEIID-5648?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-5648: ------------------------------------- I thought you are trying to just hide the SYS and SYSADMIN schemas with this effort? I remember a conversation, in OData they explicitly avoided hiding the metadata from full form on a given schema. > Hide metadata over odata > ------------------------ > > Key: TEIID-5648 > URL: https://issues.jboss.org/browse/TEIID-5648 > Project: Teiid > Issue Type: Quality Risk > Components: OData > 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. > 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. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5648) Hide metadata over odata

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5648?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5648: --------------------------------------- This would effectively entail generating a different edm metadata for every role combination or pushing a lot of logic into the olingo serialization layer. Neither of those options are appealing. I think the best thing to do is to simply assume that you want to expose the whole model, and allow a service layer, such as 3scale, to actually restrict access. So I'll introduce a more formal concept of a metadata read permission that will automatically be assigned to the odata role. > Hide metadata over odata > ------------------------ > > Key: TEIID-5648 > URL: https://issues.jboss.org/browse/TEIID-5648 > Project: Teiid > Issue Type: Quality Risk > Components: OData > 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. > 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. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5696) Misc. PG issues to support lo functionality

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5696?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-5696: ---------------------------------- Fix Version/s: 12.2 > Misc. PG issues to support lo functionality > ------------------------------------------- > > Key: TEIID-5696 > URL: https://issues.jboss.org/browse/TEIID-5696 > Project: Teiid > Issue Type: Sub-task > Components: ODBC > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.2 > > > Creating a subtask to commit the work started under the parent. > - add pg_catalog functions to pg_proc > - make the metadata between functions and procedures consistent. add the schemauid to function, and the procedure uid procedureparams > - refine the function call/response logic > - correct the functions pk/fk. it needs to include the uid as name is not unique -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5648) Hide metadata over odata

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5648?page=com.atlassian.jira.plugin... ] Work on TEIID-5648 started by Steven Hawkins. --------------------------------------------- > Hide metadata over odata > ------------------------ > > Key: TEIID-5648 > URL: https://issues.jboss.org/browse/TEIID-5648 > Project: Teiid > Issue Type: Quality Risk > Components: OData > 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. > 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. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5699) Remove the engine/runtime dependency on vfs

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5699?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5699. ----------------------------------- Resolution: Done Created another virtualfile interface so that the engine/runtime can just use nio. The server/legacy metadata will still use vfs. JBoss logging could now be more easily removed, but it's small dependency, so that's not imperative. > Remove the engine/runtime dependency on vfs > ------------------------------------------- > > Key: TEIID-5699 > URL: https://issues.jboss.org/browse/TEIID-5699 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.2 > > > We don't need a hard dependency on vfs as we can get zip filesystem handling from nio. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5699) Remove the engine/runtime dependency on vfs

by Steven Hawkins (Jira)

Steven Hawkins created TEIID-5699: ------------------------------------- Summary: Remove the engine/runtime dependency on vfs Key: TEIID-5699 URL: https://issues.jboss.org/browse/TEIID-5699 Project: Teiid Issue Type: Quality Risk Components: Query Engine Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 12.2 We don't need a hard dependency on vfs as we can get zip filesystem handling from nio. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5697) Create a sub-module for xml functionality

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5697?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5697. ----------------------------------- Resolution: Done Created teiid-optional-xml to isolate the saxon, saxon-xom, xom, xerces, and xalan (although it looks like jaxen is used in wildfly). Updated the docs about the proper exclusion. > Create a sub-module for xml functionality > ----------------------------------------- > > Key: TEIID-5697 > URL: https://issues.jboss.org/browse/TEIID-5697 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.2 > > > Similar to TEIID-5694, we should look to isolate as much of saxon and related dependencies from the engine. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5695) Add OpenAPI 3.0 metadata over OData

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5695?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5695. ----------------------------------- Resolution: Done Expanded the 2.0 support to also generate 3.0. > Add OpenAPI 3.0 metadata over OData > ----------------------------------- > > Key: TEIID-5695 > URL: https://issues.jboss.org/browse/TEIID-5695 > Project: Teiid > Issue Type: Enhancement > Components: OData > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.2 > > > OpenAPI 3.0 support is coming (even though it's not in 3 Scale yet), so we should add an option to generate 3.0 metadata. > As discussed on TEIID-5555 we'll likely use /openapi.json for this. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3522) Provide Data Aggregation Extension to OData V4

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-3522?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3522: --------------------------------------- > So from your last comment, I am wondering if group by functionality will be implemented on top level aggregates or not? Thanks for the info. It's unlikely that this will make it into 12.2 as it needs to at least also support group by and pre/post aggregate filtering (effectively where and having clauses). > Provide Data Aggregation Extension to OData V4 > ---------------------------------------------- > > Key: TEIID-3522 > URL: https://issues.jboss.org/browse/TEIID-3522 > Project: Teiid > Issue Type: Feature Request > Components: OData > Reporter: Ramesh Reddy > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.2 > > > OData V4 specification defines extension for Data Aggregation http://docs.oasis-open.org/odata/odata-data-aggregation-ext/v4.0/cs01/oda... > Teiid should provide support for this extension. There is Olingo support on this yet. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 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: --------------------------------------- > However, seems I do not end up with a decent query plan anymore. That seems odd. Are you saying that you did get better plans and then something changed? In any event you'd have to provide more details to make it clear as to what you are seeing. > Are the two fixes you mentioned already included in the most recent Teiid release? I would than switch to this version, in hope this solves the topic. Once an issue is marked as resolved the resolved versions show what releases it is in. TEIID-5682 is not resolved. TEIID-5683 is resolved for 12.2. > 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: 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)

5 years, 9 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