> 1. There are column types that correspond to types that are not defined by > the spec such as Boolean, UUID, Timestamp, Decimal, Double, Float etc.. Will > these types always a serialized java type? What happens if Java doesn't > define a size or byte order? Are these defined in a cassandra doc somewhere?
The exact layout of those types are indeed not in the specification, honestly mostly out of laziness (so that might be fixed whenever "someone" takes the time to add it). But concretely, one way to get an authoritative answer would be to look at https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=src/java/org/apache/cassandra/cql3/ParsedType.java;hb=HEAD to get the cql3->AbstractType correspondence and then look at the corresponding classes in https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree;f=src/java/org/apache/cassandra/db/marshal It may that there is some user-friendly doc of the layout of those type somewhere but I'm not sure where. Though pretty much any existing client library will have had to serialize/deserialize those same types so there's plently of references in code form at least. Note that for the most part, you can probably infer their definition from the description at http://cassandra.apache.org/doc/cql3/CQL.html#types. > 2. This is more feedback then a question: [option] is an [int][string], > except that the string only exists if [int] is 0x00 when returning rows from > a query result. That's not true. [option] is an [int] followed by some bytes, potentially none, that depends on that first [int]. And in practice, on top of 0x00, collection types (i.e. 0x020, 0x021 and 0x022) all uses the subsequent bytes and not as a [string]. > 3. Right now global keyspace and global table flags are not being used in my > test query results, this means that columns returned could possibly come from > multiple tables. As a result the methods on my row class need parameters for > keyspace, table, and column (cql_row_t::get_string(k, t, c)) for all cases, > CQL currently lacks a join so there is no reason why the global flag wouldn't > be set. Is this a bug? There is 2 places in the spec that uses the <metadata> part described in 4.2.5.2 (the one using the global table flag): a 'Rows' result set (the one described by 4.2.5.2) and that correspond to the result of a SELECT and 'Prepared' result (described in 4.2.5.4). In the first case, it is true that Cassandra not having joins, you cannot have columns from different tables and the global table flag can always be set. Do you observe otherwise? And if so do you have an example? It is certainly the intent that the server would set the global flag in that case and from a quick check of the code, it's seems to be the case but but if you see otherwise then yes it could be a "bug" indeed. For the second case, the result to a prepare, there is no guarantee at all that all columns will be in the same table (if it's a BATCH), so in that case the global table flag may or may not be set. Now can you have your API for resultSet assume all columns are in the same table? All I can tell you is that it's the case today and as far as I know there is no plan to add any form of joins any time soon. > Also, the reference Java driver always assumes the same keyspace and table, > which given that there is no join is correct, but is an incorrect > implementation according to the spec. What is it you call "the reference Java driver"? If it's https://github.com/datastax/java-driver, then no, as far as I can tell it doesn't assume the same keyspace and table (or you'd have to be more precise on where you thing it assumes that because it is not the intent). -- Sylvain
