You are free to use BytesType if you want, but adding meaningful types has the advantage of adding a checked documentation of what is stored in your CF. Or in other words:
- If multiple applications/users access the same CF, it's a documentation on what you can expect to get and what you are expected to write. If you use BytesType, you need some other mean of documenting what exactly is stored and when.  Otherwise, you'll basically have to check all the code that ever insert something in the CF to know what to expect when you read it. And if you use a Cassandra type, it is enforced by the database (contrarily to some external documentation).
- Those types are accessible to external tools, like client libraries that may therefore provide a number of facilities. 

Now, there is case where the types Cassandra provides are not flexible enough to do what you want to do, and then it can make sense to default to BytesType, but otherwise I would stick to using types as much as possible as long as it makes sense because imo the benefits are huge (and the bigger your applications are, the more the benefits mentioned above matters).


On Thu, Nov 1, 2012 at 2:42 PM, Ertio Lew <> wrote:
Would that do any harm or are there any downsides, if I store columns with composite names or Integer type names in a column family with bytesType comparator & validator. I have observed that bytesType comparator would also sort the integer named columns in similar fashion as done by IntegerType comparator, so why should I just lock my CF to just store Integer or composite named columns, would be good if I could just mix different datatypes in same column family, No !?