Includes variable-definitions in parsed query

[dat7e]

Hello,

First of all, thank you for your outstanding work on this library. Using Clojure to build GraphQL backends is a joy and lacinia enables that.

I'm currently in need of doing some dynamic analysis on lacinia queries and could not find a way to look up the consumed variables and their types. Digging into the code, it looks to me that used variables are calculated here to pass downstream, but do not make it into the returned map, therefore are not included in lacinia context.

Is it a good idea to have this value included in the context? If so I can submit a patch sometime next week. Or if there's anything I'm not aware of, please let me know.

Thank you again!

[hlship]

Could you elaborate on what you are using the variables for? Yes, we could expose how Lacinia internally tracks variables and values, but I prefer to do so carefully, in a way that allows us to change things in the future without breaking backwards compatibility. So if I had some insight into what questions you are trying to answer, that might yield a better, more stable solution.

[dat7e]

I'm working on a relational database to GraphQL API generator. For poll-based subscription optimization, the compiler has to group similar GraphQL queries into a single big SQL query to execute against the database. This requires knowing which variables are used (for the grouping), and which types they are (for appropriate SQL casts). Below is a sample:

subscription Test($name: String!) {
  Customers(
    where: {
      fullName: { _in: [$name, "Test2"] }
      id: { _neq: "47ae0cc8-9fd6-46b3-bdb8-e3bbc7c5adca" }
    }
  ) {
    id
    fullName
    createdAt
    comm
    updatedAt
    metadata
    addresses(
      where: {
        city: { _in: ["Test3", "Test4"] }
        id: { _neq: "47ae0cc8-9fd6-46b3-bdb8-e3bbc7c5adca" }
      }
    ) {
      street1
      city
      countryCode
    }
  }
}

is currently grouped into this Postgres query:

WITH __subs AS (
  SELECT 
    __subs_arr ->> 0 AS __sub_id, 
    __subs_arr ->> 1 AS name 
  FROM 
    JSON_ARRAY_ELEMENTS(
      CAST('[["43f0282c-f9e9-4644-ac31-9dcdf5095530","jj"],["another sub id","$name value for this sub"]]' AS json)
    ) AS __subs_arr
) 
SELECT 
  __sub_id AS sub_id, 
  __sub_res.result 
FROM 
  __subs 
  LEFT JOIN LATERAL (
    SELECT 
      COALESCE(
        JSONB_AGG(__root_0.*), 
        '[]'
      ) AS result 
    FROM 
      (
        SELECT 
          customer.id, 
          customer.full_name, 
          customer.created_at, 
          customer.comm, 
          customer.updated_at, 
          customer.metadata, 
          (
            SELECT 
              COALESCE(
                JSONB_AGG(__nest_1__0.*), 
                '[]'
              ) 
            FROM 
              (
                SELECT 
                  address.street_1, 
                  address.city, 
                  address.country_code 
                FROM 
                  address 
                WHERE 
                  (
                    city IN ('Test3', 'Test4')
                  ) 
                  AND (id <> '47ae0cc8-9fd6-46b3-bdb8-e3bbc7c5adca') 
                  AND (
                    address.customer_id = customer.id
                  )
              ) AS __nest_1__0
          ) AS addresses 
        FROM 
          customer 
        WHERE 
          (
            full_name IN (__subs.name, 'Test2')
          ) 
          AND (id <> '47ae0cc8-9fd6-46b3-bdb8-e3bbc7c5adca')
      ) AS __root_0
  ) AS __sub_res ON TRUE

I got to this with some hacks (i.e: using variables data from request context, which is without types and might be inaccurate). And this query works but as soon as we introduce some variables of non-primitive types, for example an "id" of UUID type:
Exception in thread "async-dispatch-8" org.postgresql.util.PSQLException: ERROR: operator does not exist: uuid <> text

For the full solution, in the WITH clause, we would need to cast values like so:

WITH __subs AS (
  SELECT 
    __subs_arr ->> 0 AS __sub_id,
    CAST(__subs_arr ->> 1 as uuid) AS id,
    CAST(__subs_arr ->> 2 as text) AS name,
    ...
  FROM 
    ...

[dat7e]

This seems to be related to #430 in that both try to enrich parsed query context.
I'd like to have your inputs on how to best move forward @hlship

[hlship]

Thanks for the update; been busy here. I'll try to digest what you have posted above.