I was wondering if there is plan to allow creating counter column and standard column in the same table.
Here is my use case: I want to use counter to count how many users like a given item in my application. The like count needs to be returned along with details of item in query. To support querying items in different ways, I use both application-maintained denormalized index tables and DSE search for indexing. (DSE search is also used for text searching) Since current counter implementation doesn't allow having counter columns and non-counter columns in the same table, I have to propagate the current count from counter table to the main item table and index tables, so that like counts can be returned by those index tables without sending extra requests to counter table and DSE search is able to build index on like count column in the main item table to support like count related queries (such as sorting by like count). IMHO, the only way to sync data between counter table and normal table within a reasonable time (sub-seconds) currently is to read the current value from counter table right after the update. However it suffers from several issues: 1. Read-after-write may not return the correct count when replication factor > 1 unless consistency level ALL/LOCAL_ALL is used 2. There are two extra non-parallelizable round-trips between the application server and cassandra, which can have great impact on performance. If it is possible to store counter in standard column family, only one write will be needed to update like count in the main table. Counter value will also be eventually synced between replicas so that there is no need for application to use extra mechanism like scheduled task to get the correct counts. A related issue is lifting the limitation of not allowing updating counter columns and normal columns in one batch, since it is quite common to not only have a counter for statistics but also store the details, such as storing the relation of which user likes which items in my user case. Any idea?
