Postgraphile: Naming conflict when building object

[mytototo]

I'm using the v2 and I encountered a naming conflict. I have a table named nodes which, I guess, creates a conflict with PostgraphQL. I unfortunately can't rename this table since it comes from an other project. Is there a work around to avoid such an error? Here is the error stack:

Error: Naming conflict when building object. Cannot have two definitions for property 'node'.

[calebmer]

This is definitely tricky. If the nodes table has no unique constraints or primary keys this probably wouldn’t happen? Also, if you don’t need a nodes table try creating a new schema (something like my_project) and put all of the tables you want PostGraphQL to introspect in there, see the forum example tutorial.

The solution I’m thinking of is renaming the node field for a single table, any ideas? Perhaps nodeSingle or node2? Or even just skipping the inclusion of such a field at all.

Now that I think about it, you’d have a conflict with the Node type name too…

This is definitely a tricky problem. We could either choose to not support tables name nodes or node, or rename such tables internally. Thoughts?

[mytototo]

I can't rename the table because it comes from the Kong open-source project. The GraphQL server I have is a bridge between a custom API portal and the Kong API gateway. So I have two PostgreSQL databases: one for the portal and one for the gateway. Renaming the nodes table from Kong would not be a suitable solution for me. Do you think row or entry can be a suitable name for PostgraphQL?

[calebmer]

Do you need to access the table from GraphQL? If not create a new schema which does not include the table.

Also, when I was talking about renaming, I really meant renaming the fields/objects in GraphQL. Not in Postgres :blush:

[mytototo]

You should not fix this "issue". It's not really an issue. I just posted so you can be aware of such conflict. To be honest I don't really care about accessing the nodes table. What is the best way to exclude a table from a schema? I have 3 schemas using PostgraphQL as an Express middleware. And I only want to exclude a few tables.

[ferdinandsalis]

You can just have schema and not have it cataloged by postgraphql. So for example you could have schema called 'kong' with aforementioned nodes table and when you setup postgraphql as middleware you just dont pass the schema to it. Would that work?

[mytototo]

@ferdinandsalis: I agree but I want to have access to most of the tables inside the schema. How can I index the schema without a specific table?

[calebmer]

Currently you’d have to create a new schema and move the tables you want to that schema, or create a new schema and add proxy views to that schema which select the underlying base tables.

I’d be interested to hear a proposal for more fine grained inclusion of tables, I currently don’t think it’s needed but a proposal could be helpful.

[mytototo]

We currently have something like this (JSON config file):

"schemas": [
  "my_schema",
  "another_schema"
]

Maybe we should add the availability to only include or exclude tables if a dot is present. Something like this:

"schemas": [
  "my_schema",
  "another_schema.a_table_i_need",
  "!another_schema.a_table_i_do_not_need"
]

[mytototo]

Or if we want a better flexibility with more possibilities:

"schemas": {
  "my_schema": "all",
  "another_schema": {
    "only": [
      "a_table_i_need"
    ],
    "exclude": [
      "a_table_i_do_not_need"
    ]
  }
}

[chrisurlaub]

I just experienced a similar case: there was a conflict because I had a table named "queries" which produces this error:

Error: Naming conflict when building object. Cannot have two definitions for property 'query'.

Perhaps there should be at least a list with something like "reserved keywords/tablenames".

[benjie]

👍 Added a wiki page: https://github.com/calebmer/postgraphql/wiki/Reserved-Keywords-Tablenames

[benjie]

[semi-automated message] Hi, there has been no activity in this issue for over 8 weeks so I'm closing it to keep the issues/pull request manageable. If this is still an issue, please re-open with a comment explaining why.