June 2019 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-5704) Support openapi 3 sources

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5704?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5704: --------------------------------------- I've started taking a look at this. It will be a fork of the current logic, but it looks like they could just be under the same translator module. It looks like about 2 days of effort. > Support openapi 3 sources > ------------------------- > > Key: TEIID-5704 > URL: https://issues.jboss.org/browse/TEIID-5704 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.3 > > > It seems like a good idea to introduce a new translator, rather than trying to fit openapi 3 support onto the swagger translator - as the io.swagger libraries and a lot of logic will be different. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-62) OpenApi 3.0 Support for OData

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIIDSB-62?page=com.atlassian.jira.plugin... ] Steven Hawkins edited comment on TEIIDSB-62 at 6/10/19 1:16 PM: ---------------------------------------------------------------- > The ask is to have "openapi.json" as the endpoint if we change to anything else it may not serve the need. I think the ask was to not use anything with swagger in the url. Whether it's opeanapi, openapi.json, or openapi_v2.json shouldn't matter correct? > openapi.json with accepts header map to 3.0 Which is a small breaking change... So we can (updating based upon another thread): 1. just use openapi_v2.json for the 2.0 document. 2. follow microprofile and make /openapi require a json content type and return the 3.0 document by default (as per the spec). openapi v2 would be served by including some other header or query parameter value. was (Author: shawkins): > The ask is to have "openapi.json" as the endpoint if we change to anything else it may not serve the need. I think the ask was to not use anything with swagger in the url. Whether it's opeanapi, openapi.json, or openapi_v2.json shouldn't matter correct? > openapi.json with accepts header map to 3.0 Which is a small breaking change... So we can: 1. follow microprofile and make /openapi require a json content type and return the 2.0 document. openapi.json would continue to server the 3.0 document. 2. just use openapi_v2.json for the 2.0 document. 3. reuse openapi.json for both 2 and 3 and specify what header we expect as the discriminator. I prefer the solutions in that order - 1 is based upon some reference. 2 is a very small code change. 3 is a small breaking change and requires the use of a non-standard header property. > OpenApi 3.0 Support for OData > ----------------------------- > > Key: TEIIDSB-62 > URL: https://issues.jboss.org/browse/TEIIDSB-62 > Project: Teiid Spring Boot > Issue Type: Feature Request > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Priority: Major > Fix For: 1.1.0 > > > Support OpenAPI 3.0 document generation with OData service -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-62) OpenApi 3.0 Support for OData

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIIDSB-62?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIIDSB-62: --------------------------------------- > The ask is to have "openapi.json" as the endpoint if we change to anything else it may not serve the need. I think the ask was to not use anything with swagger in the url. Whether it's opeanapi, openapi.json, or openapi_v2.json shouldn't matter correct? > openapi.json with accepts header map to 3.0 Which is a small breaking change... So we can: 1. follow microprofile and make /openapi require a json content type and return the 2.0 document. openapi.json would continue to server the 3.0 document. 2. just use openapi_v2.json for the 2.0 document. 3. reuse openapi.json for both 2 and 3 and specify what header we expect as the discriminator. I prefer the solutions in that order - 1 is based upon some reference. 2 is a very small code change. 3 is a small breaking change and requires the use of a non-standard header property. > OpenApi 3.0 Support for OData > ----------------------------- > > Key: TEIIDSB-62 > URL: https://issues.jboss.org/browse/TEIIDSB-62 > Project: Teiid Spring Boot > Issue Type: Feature Request > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Priority: Major > Fix For: 1.1.0 > > > Support OpenAPI 3.0 document generation with OData service -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-62) OpenApi 3.0 Support for OData

by Ramesh Reddy (Jira)

[ https://issues.jboss.org/browse/TEIIDSB-62?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIIDSB-62: ------------------------------------- The ask is to have "openapi.json" as the endpoint if we change to anything else it may not serve the need. I would say swagger.json or openapi.json map to the 2.0 openapi.json with accepts header map to 3.0 > OpenApi 3.0 Support for OData > ----------------------------- > > Key: TEIIDSB-62 > URL: https://issues.jboss.org/browse/TEIIDSB-62 > Project: Teiid Spring Boot > Issue Type: Feature Request > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Priority: Major > Fix For: 1.1.0 > > > Support OpenAPI 3.0 document generation with OData service -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-62) OpenApi 3.0 Support for OData

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIIDSB-62?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIIDSB-62: --------------------------------------- > I do not think even MP did not have a way to distinguish the version, they only made the YML as the default format. I don't 3scle supports YML or not, so yes, for now, json support is enough. Correct. The reasoning is that the service author is explicitly choosing to create a v2 or a v3 service with the given metadata contract - there's no expectation that they would support both openapi versions. How about we just do: swagger.json or openapi_v2.json map to the 2.0 metadata That would be a very small code change. > OpenApi 3.0 Support for OData > ----------------------------- > > Key: TEIIDSB-62 > URL: https://issues.jboss.org/browse/TEIIDSB-62 > Project: Teiid Spring Boot > Issue Type: Feature Request > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Priority: Major > Fix For: 1.1.0 > > > Support OpenAPI 3.0 document generation with OData service -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5763) GENERATED_KEY returns NULL if used in INSTEAD OF INSERT Triggers in DDL files

by Christoph John (Jira)

Christoph John created TEIID-5763: ------------------------------------- Summary: GENERATED_KEY returns NULL if used in INSTEAD OF INSERT Triggers in DDL files Key: TEIID-5763 URL: https://issues.jboss.org/browse/TEIID-5763 Project: Teiid Issue Type: Bug Affects Versions: 12.2 Reporter: Christoph John Assignee: Steven Hawkins The issue arrised in: https://developer.jboss.org/message/989700#989700 Following sceanarios are given: Variant 1: Table Product(id), primary key = autoincrement; Table QuicklyAddedProduct, primary key is foreign key on Product.id Table Diary_SRC View Diary on Diary_SRC INSTEAD OF INSERT Trigger on Diary should : -create new record on Product, -get autoincremented Product.id of new record, - create new QuicklyAddedProduct with returned Product.id as primary key - create new Diary record with QuicklyAddedProduct { INSERT a new record on Product; idProduct = CONVERT(GENERATED_KEY('idProduct'),long); // fails } Variant 2: INSTEAD OF INSERT trigger on Diary should : - create new QuicklyAddedProduct - add Quickly added prodcut to Diary additionally a INSTEAD OF trigger on QuicklyAddedProduct exists which: - creates new Product record - uses returned GENERATED_KEY(Product.id) to add record on QuicklyAddedProduct with Product.id as primary key -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-62) OpenApi 3.0 Support for OData

by Ramesh Reddy (Jira)

[ https://issues.jboss.org/browse/TEIIDSB-62?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIIDSB-62: ------------------------------------- I do not think even MP did not have a way to distinguish the version, they only made the YML as the default format. I don't 3scle supports YML or not, so yes, for now, json support is enough. > OpenApi 3.0 Support for OData > ----------------------------- > > Key: TEIIDSB-62 > URL: https://issues.jboss.org/browse/TEIIDSB-62 > Project: Teiid Spring Boot > Issue Type: Feature Request > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Priority: Major > Fix For: 1.1.0 > > > Support OpenAPI 3.0 document generation with OData service -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-62) OpenApi 3.0 Support for OData

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIIDSB-62?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIIDSB-62: --------------------------------------- > Working towards a standard is a separate issue IMO, that probably needs to be taken up with OpenApi specification committee. I'm not suggesting that we define the standard :) How about following microproflie: https://download.eclipse.org/microprofile/microprofile-open-api-1.0/micro... The default is yaml, which we'd some additional conversion logic to support, so for now we'd just require the json content type. > OpenApi 3.0 Support for OData > ----------------------------- > > Key: TEIIDSB-62 > URL: https://issues.jboss.org/browse/TEIIDSB-62 > Project: Teiid Spring Boot > Issue Type: Feature Request > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Priority: Major > Fix For: 1.1.0 > > > Support OpenAPI 3.0 document generation with OData service -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-62) OpenApi 3.0 Support for OData

by Ramesh Reddy (Jira)

[ https://issues.jboss.org/browse/TEIIDSB-62?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIIDSB-62: ------------------------------------- Working towards a standard is a separate issue IMO, that probably needs to be taken up with OpenApi specification committee. Data Integration's immediate need is to serve the 2.0 document when a user issues a "/openapi.json", how/if we want to serve a 3.0 document is subject to anybody's interpretation. I am fine with even Accept: application/x-yaml;openapi=3.0.0 3.0 will not be used until 3scale supports it. > OpenApi 3.0 Support for OData > ----------------------------- > > Key: TEIIDSB-62 > URL: https://issues.jboss.org/browse/TEIIDSB-62 > Project: Teiid Spring Boot > Issue Type: Feature Request > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Priority: Major > Fix For: 1.1.0 > > > Support OpenAPI 3.0 document generation with OData service -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5704) Support openapi 3 sources

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5704?page=com.atlassian.jira.plugin... ] Work on TEIID-5704 started by Steven Hawkins. --------------------------------------------- > Support openapi 3 sources > ------------------------- > > Key: TEIID-5704 > URL: https://issues.jboss.org/browse/TEIID-5704 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.3 > > > It seems like a good idea to introduce a new translator, rather than trying to fit openapi 3 support onto the swagger translator - as the io.swagger libraries and a lot of logic will be different. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues June 2019