[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)
5 years, 1 month
[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)
5 years, 1 month
[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)
5 years, 1 month
[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)
5 years, 1 month
[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)
5 years, 1 month
[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)
5 years, 1 month
[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)
5 years, 1 month
[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)
5 years, 1 month