Search code examples
gocassandracqlcassandra-2.0gocql

gocql SELECT * doesn't return all columns

I came across this weird behaviour while trying to implement some counters for my application. Basically, I did a counter table like so :

CREATE TABLE stats_dev.log_counters (
  date text PRIMARY KEY,
  all counter
);

Then I have some specific types of message I want to count as well, so in my Go app, I ALTER the table to add the column I didn't have before.

My app is growing, and I start to have more than 30 columns (shouldn't be more than 50) and when I want to retrieve all those counters, some columns are missing in the result.

query := s.Query(`SELECT * FROM `+_apiCountersTable+` WHERE date IN ?`, dates)
res, err := query.Iter().SliceMap()

This returns me something like 30 over 34 columns. Although, when I do the request on CQLSH :

cqlsh:stats_dev> SELECT * FROM api_counters WHERE date = 'total';

I get the proper full result. So :

  1. Does that come from my request which should be different ?
  2. Could that come from gocql driver ?
  3. Is that pattern completely stupid ?

My temporary solution is to SELECT the column names from the system.schema_columns table and to strings.Join() all of that to my SELECT query ...

Thank you very much for your help.

Solution

  • Thanks Andy for your help.

    At first, I thought that considering what you told me, I would rather do a SELCT column_name on the system.schema_columns sometimes and refresh it when I alter my table. I would just then strings.join() the columns in my SELECT FROM api_counters. It worked but if I had 2 different instances, and one would update the schema and the other would receive a GET request, this one would not know the new column still.

    And then I rearranged my ideas and found out that there was obviously an other way of doing that and I simply change for this schema : CREATE TABLE stats_dev.api_counters ( date text, description text, all counter, PRIMARY KEY (date, description) ); and I am updating the field based on the description I am expecting. So far so good.

    I knew it was definitely Option 3 : my pattern was not the best one.