[
https://issues.apache.org/jira/browse/CASSANDRA-12838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15612507#comment-15612507
]
Benjamin Lerer edited comment on CASSANDRA-12838 at 10/27/16 5:08 PM:
----------------------------------------------------------------------
Thanks for the patch.
My only nit is that I found the calls like
{{version.compareTo(ProtocolVersion.V5) >= 0}} difficult to read. I would
prefer to have something like
{{version.isGreaterOrEqualsTo(ProtocolVersion.V5)}} even if internally the
methods use {{compareTo}}.
In an offline discussion, [~snazy] mentioned to me that he would prefer a
different name than {{ProtocolVersion}} as it conflits with the java driver
class (but he won't fight for it).
As far as I am concerned, I do not have any problem with the name as the
conflict is limited to some test classes. So, I let you decide what you want to
do about it.
was (Author: blerer):
Thanks for the patch.
My only nit is that I found the call like
{{version.compareTo(ProtocolVersion.V5) >= 0 }} difficult to read. I would
prefer to have something like
{{version.isGreaterOrEqualsTo(ProtocolVersion.V5)}} even if internally the
methods use {{compareTo}}.
In an offline discussion, [~snazy] mentioned to me that he would prefer a
different name than {{ProtocolVersion}} as it conflits with the java driver
class (but he won't fight for it).
As far as I am concerned, I do not have any problem with the name as the
conflict is limited to some test classes. So, I let you decide what you want to
do about it.
> Extend native protocol flags and add supported versions to the SUPPORTED
> response
> ---------------------------------------------------------------------------------
>
> Key: CASSANDRA-12838
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12838
> Project: Cassandra
> Issue Type: Sub-task
> Components: CQL
> Reporter: Stefania
> Assignee: Stefania
> Fix For: 3.x
>
>
> We already use 7 bits for the flags of the QUERY message, and since they are
> encoded with a fixed size byte, we may be forced to change the structure of
> the message soon, and I'd like to do this in version 5 but without wasting
> bytes on the wire. Therefore, I propose to convert fixed flag's bytes to
> unsigned vints, as defined in CASSANDRA-9499. The only exception would be the
> flags in the frame, which should stay as fixed size.
> Up to 7 bits, vints are encoded the same as bytes are, so no immediate change
> would be required in the drivers, although they should plan to support vint
> flags if supporting version 5. Moving forward, when a new flag is required
> for the QUERY message, and eventually when other flags reach 8 bits in other
> messages too, the flag's bitmaps would be automatically encoded with a size
> that is big enough to accommodate all flags, but no bigger than required. We
> can currently support up to 8 bytes with unsigned vints.
> The downside is that drivers need to implement unsigned vint encoding for
> version 5, but this is already required by CASSANDRA-11873, and will most
> likely be required by CASSANDRA-11622 as well.
> I would also like to add the list of versions to the SUPPORTED message, in
> order to simplify the handshake for drivers that prefer to send an OPTION
> message, rather than rely on receiving an error for an unsupported version in
> the STARTUP message. Said error should also contain the full list of
> supported versions, not just the min and max, for clarity, and because the
> latest version is now a beta version.
> Finally, we currently store versions as integer constants in {{Server.java}},
> and we still have a fair bit of hard-coded numbers in the code, especially in
> tests. I plan to clean this up by introducing a {{ProtocolVersion}} enum.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
