Question

This question is about this article of Datastax. In its "Non compact tables" sub-topic, it says

The difference is that the definition above will internally use a CompositeType comparator with a single UTF8Type component, instead of an UTF8Type comparator. This may seem wasteful (technically, the use of CompositeType adds 2 bytes of overhead per internal cells (hence the compact/non-compact terms)), but the reason for that is collections support. Internally, collections require the use of CompositeType.

My question is about the last line. It says Collections need CompositeType comparator. In the example given in above quote, when we use compact storage, it doesn't give a CompositeType comparator, but a UTF8Type comparator. So collections can't be used with that. I get that.

But, if you have 2 PRIMARY KEYS, you get CompositeType comparator even with Compact Storage. Then why can't we have collections in that case?

A possible reason would be having a CompositeType comparator is not the only requirement for Collections. If it is, what are the other requirements?

Thanks.

Was it helpful?

Solution

It has to be the specific CompositeType that non-compact storage creates. This allows the collection name to be one of the comparator components.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top