Should PREPARE QUERY return metadata for the query result?

[Ben Hood <0x...@gmail.com>]

Hi all,

I'm looking at the specification of statement preparation (section
4.2.5.4 of the CQL protocol) and I'm wondering whether the metadata
result of the PREPARE query only returns column information for the
query arguments, and not for the columns of the actual query result.

The background is that we're changing gocql to expose this column
information to applications in a more useful way and we've noticed
that we only get the query argument meta data back from the server.

In practice, this might not be an issue, since the RESULT ROWS
contains the necessary column metadata.

But I was wondering if we were doing something wrong by not returning
the result meta data from the PREPARE result (if it does indeed
exist).

Can anybody shed any light on this?

Thanks,

Ben

Re: Should PREPARE QUERY return metadata for the query result?

[Ben Hood <0x...@gmail.com>]

On Wed, Jul 23, 2014 at 12:07 PM, Ben Hood <0x...@gmail.com> wrote:
> Or have I just been looking at the wrong version of the spec all along?

So it turns out that this is a case of PEBCAK: v2 of the protocol is
formulated thusly:

4.2.5.4. Prepared

  The result to a PREPARE message. The rest of the body of a Prepared result is:
    <id><metadata><result_metadata>
  where:
    - <id> is [short bytes] representing the prepared query ID.
    - <metadata> is defined exactly as for a Rows RESULT (See section
4.2.5.2; you
      can however assume that the Has_more_pages flag is always off) and
      is the specification for the variable bound in this prepare statement.
    - <result_metadata> is defined exactly as <metadata> but correspond to the
      metadata for the resultSet that execute this query will yield. Note that
      <result_metadata> may be empty (have the No_metadata flag and 0
columns, See
      section 4.2.5.2) and will be for any query that is not a Select. There is
      in fact never a guarantee that this will non-empty so client
should protect
      themselves accordingly. The presence of this information is an
      optimization that allows to later execute the statement that has been
      prepared without requesting the metadata (Skip_metadata flag in EXECUTE).
      Clients can safely discard this metadata if they do not want to take
      advantage of that optimization.

  Note that prepared query ID return is global to the node on which the query
  has been prepared. It can be used on any connection to that node and this
  until the node is restarted (after which the query must be reprepared).

Sorry for the noise on the list.

Re: Should PREPARE QUERY return metadata for the query result?

[Ben Hood <0x...@gmail.com>]

On Wed, Jul 23, 2014 at 11:14 AM, Ben Hood <0x...@gmail.com> wrote:
> But I was wondering if we were doing something wrong by not returning
> the result meta data from the PREPARE result (if it does indeed
> exist).

Looking into this a bit further, it looks like the client driver needs
to deserealize 2 blocks of meta data from PREPARE message, i.e. invoke
whatever routine parses the meta data twice to get result column meta
data.

So if this is correct, then the correct frame definition of the RESULT
of a PREPARE message should look like this:

The result to a PREPARE message. The rest of the body of a Prepared result is:
    <id><metadata><metadata>
  where:
    - <id> is [short bytes] representing the prepared query ID.
    - <metadata> is defined exactly as for a Rows RESULT (See section
4.2.5.2) - this represents the type information for the query
arguments
    - <metadata> is defined exactly as for a Rows RESULT (See section
4.2.5.2) - this represents the type information for the query result
columns

Does this make sense to anybody?

Or have I just been looking at the wrong version of the spec all along?