cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tyler Hobbs (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6855) Native protocol V3
Date Tue, 01 Apr 2014 19:14:16 GMT


Tyler Hobbs commented on CASSANDRA-6855:

I haven't gotten to review this in depth, but one thing I'd like to add support for is warnings.
 These could be a field on RESULT messages (and possibly others).  Mainly we need these for
deprecation warnings, but I'm sure there are other cases where these would be handy.

> Native protocol V3
> ------------------
>                 Key: CASSANDRA-6855
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
>             Fix For: 2.1 beta2
> I think we need a V3 of the protocol for 2.1. The things that this could/should includes
> # 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

View raw message