Implementing a driver for cassandra native protocol v2
Hello, I'm currently implementing an Erlang driver for Cassandra's binary protocol v2. Most of it is straightforward, but I came across this part in [4.1.4. QUERY]: > is a [byte] whose bits define the options for this query and > in particular influence what the remainder of the message contains. > A flag is set if the bit corresponding to its `mask` is set. Supported > flags are, given there mask: > 0x01 : ... > 0x02 : ... > 0x03 : ... > 0x04 : ... Does that mean that the 0x01 flag is set if `1 << 0` is set? and 0x03 is set if `1 << 2` is set? Thanks in advance Mathieu
Re: Implementing a driver for cassandra native protocol v2
Great, then I guess the same issue applies for [4.2.5.2. Rows]. Le Oct 28, 2013 à 10:17 AM, Sylvain Lebresne a écrit : > On Sat, Oct 26, 2013 at 8:07 PM, Mathieu D'Amours wrote: > >> Hello, >> >> I'm currently implementing an Erlang driver for Cassandra's binary >> protocol v2. Most of it is straightforward, but I came across this part in >> [4.1.4. QUERY]: >> >>> is a [byte] whose bits define the options for this query and >>>in particular influence what the remainder of the message contains. >>>A flag is set if the bit corresponding to its `mask` is set. >> Supported >>>flags are, given there mask: >>> 0x01 : ... >>> 0x02 : ... >>> 0x03 : ... >>> 0x04 : ... >> >> Does that mean that the 0x01 flag is set if `1 << 0` is set? and 0x03 is >> set if `1 << 2` is set? >> > > This is what it means, but really that's a typo. The "mask" values should > read 0x01, 0x02, 0x04, 0x08 and 0x10. I'll fix the spec. > > -- > Sylvain > > >> >> Thanks in advance >> >> Mathieu
Authentication in cassandra binary protocol v2
Hello, I stumbled upon this description in the binary protocol specs [4.2.7. AUTH_CHALLENGE]: > The body of this message is a single [bytes] token. The details of what this > token contains (and when it can be null/empty, if ever) depends on the actual > authenticator used. I looked in C* builtin authenticator classes, `AllAllowAuthenticator` and `PasswordAuthenticator`, but couldn't find this sort of information. Could someone point me in the right direction? Thanks in advance, Mathieu
Re: Authentication in cassandra binary protocol v2
I think figured it out wrong initially. I thought AUTH_CHALLENGE was the message the server sends right after STARTUP. If I understand correctly a server configured with the PasswordAuthenticator is going to expect this flow: C -> [STARTUP] S -> [AUTHENTICATE] "PasswordAuthenticator" C -> [AUTH_RESPONSE] "usernamepassword" Given correct credentials, is C* going to send both of these message one after the other? S -> [AUTH_SUCCESS] S -> [READY] The documentation about READY seem to contain artifacts from v1 (the CREDENTIALS message): > Indicates that the server is ready to process queries. This message will be > sent by the server either after a STARTUP message if no authentication is > required, or after a successful CREDENTIALS message. Thank again, Le Oct 28, 2013 à 2:48 PM, Sylvain Lebresne a écrit : > What information are you looking for? As the comment says, the details are > authenticaticator specific. So you were right to look into > PasswordAuthenticator in particular, and to be more precise you'll want to > look at PasswordAuthenticator.PlainTextSaslAuthenticator.evaluateResponse() > for that that specific authenticator expect (basically the username and > password as UTF8). > > -- > Sylvain > > > On Mon, Oct 28, 2013 at 7:15 PM, Mathieu D'Amours wrote: > >> Hello, >> >> I stumbled upon this description in the binary protocol specs [4.2.7. >> AUTH_CHALLENGE]: >> >>> The body of this message is a single [bytes] token. The details of what >> this >>> token contains (and when it can be null/empty, if ever) depends on the >> actual >>> authenticator used. >> >> >> I looked in C* builtin authenticator classes, `AllAllowAuthenticator` and >> `PasswordAuthenticator`, but couldn't find this sort of >> information. Could someone point me in the right direction? >> >> Thanks in advance, >> >> Mathieu
Lifecycle of paged queries
Hello everyone, I'd like to know how long a paged query state lives in C* before being gc'd if the client never comes and query the rest. - Matt
Data serialization from clients
Hello everyone, I just want to make sure, the set of bounds values provided along QUERY or EXECUTE requests coming from clients should be encoded in accordance with serializers found in org.apache.cassandra.serializers.* right? - Matt
Named bind variables and one-off queries
Hello again, Since C* expect a list of values for bind variables in queries, in non-prepared queries the driver has no direct information about the expected order of named variables. Is there a way to reliably predict the order of variable values C* will expect?
Re: Named bind variables and one-off queries
Sorry about that, I'm making a driver for Cassandra binary protocol v2. When the driver sends QUERY queries (unprepared), those can contain only the CQL statement, or, if there are bind variables in the statement, the values for the bind variables can be sent along the statement. Recently, C* added "named variables", and (from the driver's perspective) dealing with those for prepared queries is straightforward using the metadata that is received from cassandra after a PREPARE query. But, for unprepared queries, the client doesn't have this metadata in hand, so it doesn't know the order of variables... Cassandra obviously has its way of going from named variables in statements to a ordered list of expected values, so I was wondering how I should make sure I yield the same order as cassandra. Le Nov 20, 2013 à 11:20 AM, Tyler Hobbs a écrit : > On Wed, Nov 20, 2013 at 10:13 AM, Mathieu D'Amours wrote: > >> >> Since C* expect a list of values for bind variables in queries, in >> non-prepared queries the driver has no direct information about the >> expected order of named variables. Is there a way to reliably predict the >> order of variable values C* will expect? > > > Your question isn't clear to me. Are you concerned with prepared > statements or non-prepared statements? What are you concerned about or > what are you trying to accomplish? > > > -- > Tyler Hobbs > DataStax <http://datastax.com/>
Re: Named bind variables and one-off queries
OK, that answers my question, thank you! - Mathieu Le Nov 20, 2013 à 11:31 AM, Sylvain Lebresne a écrit : >> Since C* expect a list of values for bind variables in queries, in >> non-prepared queries the driver has no direct information about the >> expected order of named variables. Is there a way to reliably predict the >> order of variable values C* will expect? > > > No, not until you parse the statement driver side. In other word, naming > bind variables is largely useless for one-shot prepare+execute queries. > > -- > Sylvain
Cassandra documentation
Hello, In cassandra's documentation page http://www.datastax.com/documentation/cassandra/2.0/cassandra/configuration/configCassandra_yaml_r.html, in the section about start_native_transport, the following is written: > "Currently, only the Thrift server is started by default because the native > transport is considered beta." - native proto does start by default, and it's > not beta One sentence in quotes says one thing, and the following sentence says the opposite. I think it's not clear enough which one we should take into account. Thanks, Mathieu
