Is this type of counter table definition valid?

["K. Lawson" <kl...@gmail.com>]

I want to create a table with wide partitions (or, put another way, a table
which has no value columns (non primary key columns)) that enables the
number of rows in any of its partitions to be efficiently procured. Here is
a simple definition of such a table


CREATE TABLE IF NOT EXISTS test_table
> (
>     partitionKeyCol         timestamp
>     clusteringCol           timeuuid
>     partitionRowCountCol    counter    static
>     PRIMARY KEY             (partitionKeyCol, clusteringCol)
> )


The problem with this definition, and others structured like it, is that
their validity cannot be clearly deduced from the information contained in
the docs.


*What the docs do state* (with regards to counters):

   - A counter column can neither be specified as part of a table's PRIMARY
   KEY, nor used to create an INDEX
   - A counter column can only be defined in a dedicated counter table
   (which I take to be a table which solely has counter columns defined as its
   value columns)


*What the docs do not state* (with regards to counters):

   - The ability of a table to have a static counter column defined for it
   (given the unique write path of counters, I feel that this is worth
   mentioning)
   - The ability of a table, which has zero value columns defined for it
   (making it a dedicated counter table, given my understanding of the term),
   to also have a static counter column defined for it

Given the information on this subject that is present in (and absent from)
the docs, such a definition appears to be valid. However, I'm not sure how
that is possible, given that the updates to partitionRowCountCol would
require use of a write path different from that used to insert
(partitionKeyCol, clusteringCol) tuples.

Is this type of counter table definition valid? If so, how are writes to
the table carried out?

Re: Is this type of counter table definition valid?

[DuyHai Doan <do...@gmail.com>]

Just tested against C* 3.4

CREATE TABLE IF NOT EXISTS test_table (
      part timestamp,
      clust timestamp,
      count counter static,
PRIMARY KEY(part, clust));

and it just works.

"However, I'm not sure how that is possible, given that the updates to
partitionRowCountCol would require use of a write path different from that
used to insert (partitionKeyCol, clusteringCol) tuples."

--> INSERT is not allowed for counter columns, only UDPATE is possible. In
general mutation on static columns only require partition key, and it makes
no difference for static counter columns




On Thu, Mar 24, 2016 at 2:10 PM, K. Lawson <kl...@gmail.com> wrote:

>
> I want to create a table with wide partitions (or, put another way, a
> table which has no value columns (non primary key columns)) that enables
> the number of rows in any of its partitions to be efficiently procured.
> Here is a simple definition of such a table
>
>
> CREATE TABLE IF NOT EXISTS test_table
>> (
>>     partitionKeyCol         timestamp
>>     clusteringCol           timeuuid
>>     partitionRowCountCol    counter    static
>>     PRIMARY KEY             (partitionKeyCol, clusteringCol)
>> )
>
>
> The problem with this definition, and others structured like it, is that
> their validity cannot be clearly deduced from the information contained in
> the docs.
>
>
> *What the docs do state* (with regards to counters):
>
>    - A counter column can neither be specified as part of a table's
>    PRIMARY KEY, nor used to create an INDEX
>    - A counter column can only be defined in a dedicated counter table
>    (which I take to be a table which solely has counter columns defined as its
>    value columns)
>
>
> *What the docs do not state* (with regards to counters):
>
>    - The ability of a table to have a static counter column defined for
>    it (given the unique write path of counters, I feel that this is worth
>    mentioning)
>    - The ability of a table, which has zero value columns defined for it
>    (making it a dedicated counter table, given my understanding of the term),
>    to also have a static counter column defined for it
>
> Given the information on this subject that is present in (and absent from)
> the docs, such a definition appears to be valid. However, I'm not sure how
> that is possible, given that the updates to partitionRowCountCol would
> require use of a write path different from that used to insert
> (partitionKeyCol, clusteringCol) tuples.
>
> Is this type of counter table definition valid? If so, how are writes to
> the table carried out?
>