[
https://issues.apache.org/jira/browse/CASSANDRA-6855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13986621#comment-13986621
]
Michael Shuler commented on CASSANDRA-6855:
-------------------------------------------
There were a couple other tests that SpecificOptions.DEFAULT,3 indeed fixed.
Thanks!
> Native protocol V3
> ------------------
>
> Key: CASSANDRA-6855
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6855
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Fix For: 2.1 beta2
>
> Attachments: auth_test_dtest-2.1~git9872b74.node1.log,
> auth_test_dtest-2.1~git9872b74.txt
>
>
> I think we need a V3 of the protocol for 2.1. The things that this
> could/should includes are:
> # Adding an optional Serial CL for protocol batches (like we have for QUERY
> and EXECUTE). It was an oversight of V2 of not adding it, and now that we can
> batch conditional updates, it's definitively missing.
> # Proper type codes for UDT. This is not *strictly* needed to be able to
> support UDT since currently a UDT will be sent as a "custom type" with his
> fully class name + arguments. But parsing that is no fun nor convenient for
> clients. It's also not particular space efficient (though that's probably not
> a huge concern since with prepared statement you can avoid sending the
> ResultSet metadata every time).
> # Serialization format for collections. Currently the serialization format
> only allow for 65K elements, each of 65K bytes size at most. While
> collections are not meant to store large amount of data, having the
> limitation in the protocol serialization format is the wrong way to deal with
> that. Concretely, the current workaround for CASSANDRA-5428 is ugly. I'll
> note that the current serialization format is also an obstacle to supporting
> null inside collections (whether or not we want to support null there is a
> good question, but here again I'm not sure being limited by the serialization
> format is a good idea).
> # CASSANDRA-6178: I continue to believe that in many case it makes somewhat
> more sense to have the default timestamp provided by the client (this is a
> necessary condition for true idempotent retries in particular). I'm
> absolutely fine making that optional and leaving server-side generated
> timestamps by default, but since client can already provide timestamp in
> query string anyway, I don't see a big deal in making it easier for client
> driver to control that without messing with the query string.
> # Optional names for values in QUERY messages: it has been brought to my
> attention that while V2 allows to send a query string with values for a
> one-roundtrip bind-and-execute, a driver can't really support named bind
> marker with that feature properly without parsing the query. The proposition
> is thus to make it (optionally) possible to ship the name of the marker each
> value is supposed to be bound to.
> I think that 1) and 2) are enough reason to make a V3 (even if there is
> disagreement on the rest that is).
> 3) is a little bit more involved tbh but I do think having the current
> limitations bolted in the protocol serialization format is wrong in the long
> run, and it turns out that due to UDT we will start storing serialized
> collections internally so if we want to lift said limitation in the
> serialization format, we should do it now and everywhere, as doing it
> afterwards will be a lot more painful.
> 4) and 5) are probably somewhat more minor, but at the same time, both are
> completely optional (a driver won't have to support those if he doesn't
> want). They are really just about making things more flexible for client
> drivers and they are not particularly hard to support so I don't see too many
> reasons not to include them.
> Last but not least, I know that some may find it wrong to do a new protocol
> version with each major of C*, so let me state my view here: I fully agree
> that we shouldn't make an habit of that in the long run and that's
> definitively *not* my objective. However, it would be silly to expect that we
> could get everything right and forget nothing in the very first version. It
> shouldn't be surprising that we'll have to burn a few versions (and there
> might be a few more yet) before getting something more stable and complete
> and I think that delaying the addition of stuffs that are useful to create
> some fake notion of stability would be even more silly. On the bright side,
> the additions of this V3 are comparatively much more simple to implement for
> a client that those of V2 (in fact, for clients that want to support UDT, it
> will probably require less effort to add the changes for this new version
> than to try to support UDT without it), so I do think we make good progress
> on getting the protocol stabilized
--
This message was sent by Atlassian JIRA
(v6.2#6252)
