Should metadata queries and mutations use the naming convention?

[jorgebay]

Should metadata queries and mutations use the naming convention or should the names used be a reflection of the db schema?

For example, given this metadata query:

 { tables { name }}

and tables books_by_author and books_by_title in the db.

A) Then the result should be:

{
  "data": {
    "tables": [
      {
        "name": "books_by_author"
      },
      {
        "name": "books_by_title"
      }
    ]
  }
}

B) Or

{
  "data": {
    "tables": [
      {
        "name": "BooksByAuthor"
      },
      {
        "name": "BooksByTitle"
      }
    ]
  }
}

[jorgebay]

I think the goal of those queries and mutations is to allow exploring whats in the DB, and it's not directly related to graphql types... I'm leaning towards option A.

[mpenick]

What if we move the table DDL queries and mutations up to the root /graphql? Table DDL queries could be nested under the keyspaces as query-able tables/table fields. Table mutations would live at the top level, per GraphQL specification, but would take an extra keyspace parameter:

createTable(keyspace: "store", ...)

I think this could be a nice separation between DDL API and application-specific API. We'd have to modify or eliminate single keyspace mode.

[mpenick]

It would potentially be easier to explain and document the different naming conventions if they live in different areas.

[jorgebay]

Table mutations would live at the top level, per GraphQL specification, but would take an extra keyspace parameter[...]

Altering the schema as a top level operation makes sense to me. To clarify, are you suggesting:

• /graphql: DDL graphql operations. (createTable, createKeyspace, ...)
• /graphql/<ks_name>: DML graphql operations for a single ks. (insertX, updateX, xFilter(), x()...)

What "single keyspace" setups (cloud) would look like? the same? for example /graphql and/graphql/my_ks ?

[jorgebay]

This was implemented in #50 .