Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support binary protocol v3 #22

Closed
jbochi opened this issue Aug 19, 2014 · 8 comments
Closed

Support binary protocol v3 #22

jbochi opened this issue Aug 19, 2014 · 8 comments

Comments

@jbochi
Copy link
Owner

jbochi commented Aug 19, 2014

Changes from v2:

  • stream id is now 2 bytes long (a [short] value), so the header is now 1 byte longer (9 bytes total).
  • BATCH messages now have (like QUERY and EXECUTE) and a corresponding optional
    <serial_consistency> parameters (see Section 4.1.7).
  • User Defined Types and tuple types have to added to ResultSet metadata (see 4.2.5.2) and a
    new section on the serialization format of UDT and tuple values has been added to the documentation
    (Section 7).
  • The serialization format for collection has changed (both the collection size and
    the length of each argument is now 4 bytes long). See Section 6.
  • QUERY, EXECUTE and BATCH messages can now optionally provide the default timestamp for the query.
    As this feature is optionally enabled by clients, implementing it is at the discretion of the
    client.
  • QUERY, EXECUTE and BATCH messages can now optionally provide the names for the values of the
    query. As this feature is optionally enabled by clients, implementing it is at the discretion of the
    client.
  • The format of "Schema_change" results (Section 4.2.5.5) and "SCHEMA_CHANGE" events (Section 4.2.6)
    has been modified, and now includes changes related to user types.
@subnetmarco
Copy link
Contributor

+1

@jbochi
Copy link
Owner Author

jbochi commented Nov 25, 2014

Hey @thefosk. Could you please elaborate why you are interested in this feature? I think that one possible benefit is that it would be possible to implement named arguments for queries, but this does not have a high priority for me. Thanks.

@thibaultcha
Copy link
Contributor

Oh, missed this issue. Yes, +1, BATCH and named argument as well as default timestamp would be really, really useful

@subnetmarco
Copy link
Contributor

@jbochi Batching would be very useful for executing multiple operations in one request, thus optimizing performance in some scenarios.

@thibaultcha
Copy link
Contributor

@jbochi How do you wish to support v3? Should the library be backwards compatible, handled by the code, should 2 branches be maintained (say 0.x-x and 1.x-x)? Or should the support for v2 be dropped? (knowing that the Python datastax driver is said to only support v3 on their master branch)

@jbochi
Copy link
Owner Author

jbochi commented Feb 14, 2015

My initial thought was that we should provide an option for the user to choose the protocol version on library initialization, but if the official drivers are dropping the v2 support we can do that as well.

@thibaultcha
Copy link
Contributor

Just putting this here for future reference as it took me a ridiculous amount of time to find it (more than 60 seconds...). Binary protocol v3 definition:

https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=doc/native_protocol_v3.spec;hb=refs/heads/cassandra-2.1

@jbochi
Copy link
Owner Author

jbochi commented Feb 18, 2015

I guess very few people have read this document. It's indeed insanely hard
to find. :)

On Wed Feb 18 2015 at 3:33:43 AM Thibault Charbonnier <
notifications@github.com> wrote:

Just putting this here for future reference as it took me a ridiculous
amount of time to find it (more than 60 seconds...)

https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=doc/native_protocol_v3.spec;hb=refs/heads/cassandra-2.1


Reply to this email directly or view it on GitHub
#22 (comment)
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants