so I suggest instead just disallowing range queries on row keys for non-OPP for now.
I don't disagree, but I'll note that the problem is the same for indexed queries. We can only allow full-ring range slices however (maybe that's what you meant); i.e. disallow having a non-equal restriction on the row key, but allow to have no restrictions at all. As a side I'll note that imho that's yet one more reason to spit PK in two (the argument being that when you start having too many different restrictions on the first component of the PK and the others, maybe it's worth acknowledging it in the syntax).
My inclination would be if we're going to ignore it, let's set it to something obviously bogus, like -1
Sure. For some reason I cannot really explain I wanted to avoid 0 and went with 1, but -1 is better.
I have to admit I'm not a huge fan of the Restriction class
As the comments in the code says, I'm not an absolute fan either, but it was still the best I could come up at the time. The goal being to make validation and querying as fast as possible. I'm open to suggestions for a better encapsulation though.
What is CFDefinition.Name trying to encapsulate?
It's representing what I could call for lack of a better name a 'CQL column name'. I.e, the name of one of the definition in the CREATE TABLE definition. And in the case of Compact Storage, one of those 'CQL column name' happens to be the name for the C* value the record represent. So yes, there is some clash of terminology: a CQL column can be, in C*, one of: the row key, the columm name, a component of the colum name or the column value. Again, I'm open to suggestions to better names that avoid the confusion.
"Name value" declaration confuses me
So to complete my comment above, you can see CFDefinition as the correspondence between the CQL names defined in the CREATE TABLE and what they represent internally. 'Name value' is the name used to represent the C* value in the COMPACT STORAGE case. Maybe calling it value_alias would avoid the confusion? (I avoided calling them 'alias' at first, because from the CQL standpoing, they are not mere aliases but actual (CQL) column names).
In my mind a classic, dynamic CF is the simplest possible dense, not a separate type. So I'm not sure the distinction of Kind.dynamic is useful.
Yes but internally a dynamic CF don't use a composite, so it is bound to have some differences internally. That being said, now that I think about it, I should be able to make those differences even smaller by pushing them inside the CompositeType.Builder. That'll probably also merge a few differences between sparse and static.
Now that remind me of a detail that is worth mentioning. In the current patch, if you declare the following:
CREATE TABLE foo (key text, col text, value text, PRIMARY KEY (key, col)) WITH COMPACT STORAGE;
and you do a SELECT * FROM foo WHERE key = 'k', then it'll return all the record for key 'k'. But if now you declare:
CREATE TABLE foo (key text, col1 text, col2 text, value text, PRIMARY KEY (key, col1, col2)) WITH COMPACT STORAGE;
and do SELECT * FROM foo WHERE key = 'k' AND col1 = 'c', then you will only get one record back, the one where col1 is 'c' and col2 is not defined, if it exists, not all the record that have as prefix col1 == 'c'. The reason being that for dense, we allow to have only a prefix of the key to be defined, and so you can do:
INSERT INTO foo (key, col1) VALUES ('k', 'c')
One option would be to disallow doing this, but it would add an actual limitation to what is possible.