March 2019 - teiid-issues - Jboss List Archives

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

by Steven Hawkins (Jira)

Steven Hawkins created TEIID-5697: ------------------------------------- Summary: 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 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)

7 years

1
0
0 / 0

[JBoss JIRA] (TEIID-5694) Create a sub-module for geo functions

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5694?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5694: --------------------------------------- [~rareddy] See the pull request https://github.com/teiid/teiid/pull/1139 With the optional-geo removed the following will occur - and handled gracefully: - no ST_ASGEOJSON, ST_GEOMFROMGEOJSON, nor ST_TRANSFORM functions - geography values may not be valid/normalized - to gml without srid may fail - mongodb usage of geojson will fail As described above the isolation of jts-core would be even more work. To be done properly it would even take another module to isolate the interdependence with olingo. > Create a sub-module for geo functions > ------------------------------------- > > Key: TEIID-5694 > URL: https://issues.jboss.org/browse/TEIID-5694 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.2 > > > When not including the geo functionality we should see an warning, but not fail to start. The current logic will fail to start by looking directly at geometryutils to load the st_extent aggregate. It will also not fail to load the other function methods as Geo*FunctionMethods is isolated from the missing dependencies. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (TEIID-5694) Create a sub-module for geo functions

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5694?page=com.atlassian.jira.plugin... ] Steven Hawkins edited comment on TEIID-5694 at 3/21/19 9:04 AM: ---------------------------------------------------------------- Geo logic that is dependent upon other libraries is present in: - engine - runtime (pg geo support) - olingo (geo support) - mongodb In particular the olingo support requires the mapping of the jts geometry object to the corresponding olingo object, so I believe it would be best/simplest to just consider jts-core as required, but make proj4j and wololo optional. was (Author: shawkins): Geo logic that is dependent upon other libraries is present in: - engine - runtime (pg geo support) - olingo (geo support) I believe it would be best/simplest to just consider jts-core as required, but make proj4j and wololo optional. > Create a sub-module for geo functions > ------------------------------------- > > Key: TEIID-5694 > URL: https://issues.jboss.org/browse/TEIID-5694 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.2 > > > When not including the geo functionality we should see an warning, but not fail to start. The current logic will fail to start by looking directly at geometryutils to load the st_extent aggregate. It will also not fail to load the other function methods as Geo*FunctionMethods is isolated from the missing dependencies. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (TEIID-5694) Create a sub-module for geo functions

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5694?page=com.atlassian.jira.plugin... ] Steven Hawkins edited comment on TEIID-5694 at 3/20/19 7:51 PM: ---------------------------------------------------------------- Geo logic that is dependent upon other libraries is present in: - engine - runtime (pg geo support) - olingo (geo support) I believe it would be best/simplest to just consider jts-core as required, but make proj4j and wololo optional. was (Author: shawkins): Geo logic that is dependent upon other libraries is present in: - engine - runtime (pg geo support) - olingo (geo support) > Create a sub-module for geo functions > ------------------------------------- > > Key: TEIID-5694 > URL: https://issues.jboss.org/browse/TEIID-5694 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.2 > > > When not including the geo functionality we should see an warning, but not fail to start. The current logic will fail to start by looking directly at geometryutils to load the st_extent aggregate. It will also not fail to load the other function methods as Geo*FunctionMethods is isolated from the missing dependencies. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (TEIID-5694) Create a sub-module for geo functions

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5694?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5694: --------------------------------------- Geo logic that is dependent upon other libraries is present in: - engine - runtime (pg geo support) - olingo (geo support) > Create a sub-module for geo functions > ------------------------------------- > > Key: TEIID-5694 > URL: https://issues.jboss.org/browse/TEIID-5694 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.2 > > > When not including the geo functionality we should see an warning, but not fail to start. The current logic will fail to start by looking directly at geometryutils to load the st_extent aggregate. It will also not fail to load the other function methods as Geo*FunctionMethods is isolated from the missing dependencies. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

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 resolved TEIID-5696. ----------------------------------- Resolution: Done Addressed the items listed in the description. > 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 > > 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)

7 years

1
0
0 / 0

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

by Steven Hawkins (Jira)

Steven Hawkins created TEIID-5696: ------------------------------------- Summary: 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 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)

7 years

1
0
0 / 0

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

by Steven Hawkins (Jira)

Steven Hawkins created TEIID-5695: ------------------------------------- Summary: 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 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)

7 years

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 updated TEIID-5695: ---------------------------------- Fix Version/s: 12.2 > 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)

7 years

1
0
0 / 0

[JBoss JIRA] (TEIID-5624) Implement LO function support for pg/ODBC

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5624?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5624: --------------------------------------- Thinking through this a little more it seems like this will duplicate all of the engine lob tracking logic - including the need to hold statements/source results open to keep the lobs readable. This just doesn't seem like a good fit. The closest we could come would be to have the user explicitly introduce a lobid integer column to any table with a lob, then introduce a well named view, for example teiid_largeobjects that contained the lobid / lob value. The user would have to ensure that all lob ids were unique across the vdb. The teiid_largeobjects would look something like: select lobid, lob from table1 where lobid between ... unnion all select lobid, lob from table2 where lobid between ... so that we could easily filter the union branches. Then our logic for lo_open would need to reference the teiid_largeobjects table. However this is not very turn-key, so I don't think we should pursue it at this time. > Implement LO function support for pg/ODBC > ----------------------------------------- > > Key: TEIID-5624 > URL: https://issues.jboss.org/browse/TEIID-5624 > Project: Teiid > Issue Type: Feature Request > Components: ODBC > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > > The current logic maps lobs to bytea and text types and caps their length by default to 2MB. We should add actual lob support using the LO functions. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues March 2019