"schema 'public' contains table 'geography_columns'" about crystal HOT 10 CLOSED

How are you starting PostGraphQL? Are you setting a specific schema?

from crystal.

@calebmer My databases are also all PostGIS enabled and got the same exception. PostGIS creates some views and tables in the public schema. I think the tables/views in question are those:

  Schema  |       Name        |   Type   | Owner 
----------+-------------------+----------+-------
 public   | geography_columns | view     | roman
 public   | geometry_columns  | view     | roman
 public   | raster_columns    | view     | roman
 public   | raster_overviews  | view     | roman
 public   | spatial_ref_sys   | table    | roman

Would be nice to exlude them somehow. Otherwise can't wait to try this out.

from crystal.

This is how I ran it node dist/main.js postgres://localhost:5432/seven --development.

I was testing this on a database managed by django migrations which I guess puts everything in the public schema. In another database which doesn't use PostGIS everything worked correctly.

from crystal.

If you use the --schema option you can specify the exact schema to use, otherwise PostGraphQL will default to the public schema (and so all the PostGIS stuff 😊). So:

postgraphql postgres://localhost:5432 --schema my_schema --development

Does that work for you? I just added an example: here if you are curious.

from crystal.

I tried that, but it seems it put it all in the public schema.

from psql:

*****=# \dn
List of schemas
  Name  | Owner
--------+-------
 public | cp
(1 row)

from crystal.

Postgres queries have a schema lookup path; you can actually put the tables you care about for GraphQL in one schema and the postgis tables in another schema and queries will "fall back to" the secondary schema as long as you've set your search path. More generally, though, I think it would be helpful to be able to specify, somehow, an explicit list of tables to expose, or at the very least warn but not fail on tables without primary keys.

from crystal.

@myndzi agreed, the reason I require a primary key is to implement the Relay Node interface, but on further thought, that constraint really isn't necessary. All tables don't need to be nodes.

from crystal.

@cmpis try:

create schema my_schema;

create table my_schema.my_table (…);

-- or to move a table:

alter table my_current_table set schema my_schema;

If you don't like prefixing all your tables with the schema name (my_table) the example schema uses a schema lookup path like @myndzi recommends.

I'm removing the error for tables without primary keys now, but it is recommended to have all of your relevant tables in a single schema for PostGraphQL or else it will expose everything in the public schema.

from crystal.

Primary keys are no longer required as of #10/version 1.1.0. I'll wait for feedback and then close this issue.

Also, I've started a Gitter room if you want to talk about your experiences with PostGraphQL. Also, if you'd like to contribute I want to adopt an open-open source governance model so core collaborators have direct commit rights on the repo (only makes sense as PostGraphQL is definitely a critical dependency).

from crystal.

Closing as this fixed in 1.1.0 🎉

from crystal.