4 ms·

Overall this is great, and I am thoroughly impressed. I have a couple criticisms though. 1. The API documentation is incomplete. I know this is fairly new, but

by rpedela 12y ago

Overall this is great, and I am thoroughly impressed. I have a couple criticisms though. 1. The API documentation is incomplete. I know this is fairly new, but information about upsert and the other operations mentioned in the intro video would be helpful. 2. I don't like abusing schemas for versioning. I understand the purpose and I think there are many use cases where this is desirable. However what happens when you need to query tables and views in multiple schemas? There are cases where you could use schema search path tricks, but there are cases where you can't and I have such a use case. I would prefer being able to disable versioning and set the schema in the route.

joevandyk 12y ago
Why wouldn't you be able to query tables/views in multiple schemas?
- rpedela 12y ago
  You can. I didn't say you couldn't absolutely, rather there are cases where you can't. Using the schema search path and/or joining multiple tables into a view allows you to query multiple schemas. The internal schema and relation structure doesn't matter. But since this tool takes over setting the schema for versioning at the API level, the end result is that, from the API's point of view, there is only one schema in the database. My question remains, how do I expose multiple schemas in the REST API? I certainly could have missed something, but it doesn't seem like it is possible to expose multiple schemas in the REST API itself. This tool seems more geared toward providing a public REST API where the data happens to be stored in Postgres rather than a more generic REST API for Postgres. I would like the latter, but if that isn't the goal then that is okay.
  - joevandyk 12y ago
    I'm not exactly sure what you mean by "expose multiple schemas in the REST API" - you mean pg schemas or how the API is structured? (I wish pg named schemas "namespaces" or something else, schema is an overloaded term)
    - rpedela 12y ago
      Yes I agree with using the term namespace instead of PG schema. I have also never understood why the default schema (namespace) is called "public". Why not "default"? Anyway let us say how do I expose multiple namespaces in the REST API?

by rpedela 12y ago

joevandyk 12y ago

Why wouldn't you be able to query tables/views in multiple schemas?

rpedela 12y ago
You can. I didn't say you couldn't absolutely, rather there are cases where you can't. Using the schema search path and/or joining multiple tables into a view allows you to query multiple schemas. The internal schema and relation structure doesn't matter. But since this tool takes over setting the schema for versioning at the API level, the end result is that, from the API's point of view, there is only one schema in the database. My question remains, how do I expose multiple schemas in the REST API? I certainly could have missed something, but it doesn't seem like it is possible to expose multiple schemas in the REST API itself. This tool seems more geared toward providing a public REST API where the data happens to be stored in Postgres rather than a more generic REST API for Postgres. I would like the latter, but if that isn't the goal then that is okay.
- joevandyk 12y ago
  I'm not exactly sure what you mean by "expose multiple schemas in the REST API" - you mean pg schemas or how the API is structured? (I wish pg named schemas "namespaces" or something else, schema is an overloaded term)
  - rpedela 12y ago
    Yes I agree with using the term namespace instead of PG schema. I have also never understood why the default schema (namespace) is called "public". Why not "default"? Anyway let us say how do I expose multiple namespaces in the REST API?