-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable ssl #17
base: develop
Are you sure you want to change the base?
Enable ssl #17
Conversation
Add an `ssl` object based on [`ISSLConfig` interface](https://github.com/vitaly-t/pg-promise/blob/master/typescript/pg-subset.d.ts#L62-L72)
ESRI Feature Services can support tables, which have no geometry. This change keeps the provider from erroring when reading postgres tables that have no geometry but can still be served as a Feature Layer
Thanks @saltaverde, do you have an example of some data to test against? |
@doneill It could be pretty much any table that doesn't have a column of type For example create table test_data as (select (random() * 1000 + 1)::integer as id, substr(md5(random()::text), 1, 25) as name from generate_series(0, 9)); |
const geom = result.f_geometry_column | ||
const srid = result.srid | ||
const geom = result?.f_geometry_column || 'null' | ||
const srid = result?.srid || 'null' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is your intention with these values? I have refactored this module on the develop
branch and plan to update with something like the following:
const result = await db.data.getGeometryColumnName(schema, table);
if (!result) {
throw new Error('Invalid result from getGeometryColumnName');
}
To error out gracefully.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ESRI Feature Services can support tables, which have no geometry. This
change keeps the provider from erroring when reading postgres tables
that have no geometry but can still be served as a Feature Layer
My intention is to be able to serve a table (no geometry) in a feature service. We have a use case where we are using Koop to create a feature service with tables for our Survey123 app to query and dynamically populate choices in the survey. When doing this initially I ran into exceptions because the postgres table had no columns of type geometry
. The workaround I found was to set these to null
and then Koop served a table as expected. Erroring gracefully here is still erroring when this is a case that Koop supports.
@saltaverde Can you change the base branch to |
@saltaverde not sure if this is still relevant, but v1.0.9 generates an empty json object when geometry column not available on the table. Not sure if that is what you would expect, but the provider doesn't error out now. |
Enable SSL connections to the database
Add an
ssl
object based onISSLConfig
interface
Allow for
null
geometry and sridESRI Feature Services can support tables, which have no geometry. This
change keeps the provider from erroring when reading postgres tables
that have no geometry but can still be served as a Feature Layer