[
https://issues.apache.org/jira/browse/CASSANDRA-6855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13957675#comment-13957675
]
Sylvain Lebresne commented on CASSANDRA-6855:
---------------------------------------------
While I'm not necessarily against in principle, I'm not entirely sold for
practical reasons. First, we already had to handle a few minor deprecation and
so far we've logged a warning in the log. And while it's not "perfect", it
doesn't feel too bad either to me especially since we shouldn't deprecate stuff
all the time. This to say that while sending the deprecation warning to the
client would be nice, it doesn't seem absolutely necessary to me. On the cons
side of things, I don't see a very clean way to add this to all possible type
of RESULT messages without adding some bytes even when no warning is sent
(which will be by far the majority of case): it's trivial to add a new flag to
Result.Rows messages, because we have the <flags> and we can dedicate one bit
for an optional warning message easily, but for Result.Void, we can't make it
entirely "optional" (unless maybe we create a new Result.Void_with_warning
type, but that feels rather ugly). Sure just adding a warning field to
Result.Void, just having it be the empty string when there is no warning, is
only 2 bytes of overhead, but it's 2 bytes that is sent all the time for
something that is very rarely needed, and is really just a convenience when it
is. There is also the fact that currently we wouldn't have much use of this.
So, well, that doesn't seem too useful as of now, and I'm not too sure how to
add it cleanly/without adding overhead in general. That said, if you have a
concrete proposition, I'm fine looking at it.
But *please*, lets not that slow down the review of what's already here. As
long as we decide what we want to do for this warnings idea before the final
release of 2.1, we can deal with it asynchronously from the bulk of this issue
(at best this should be minor modification anyway). And I really think the
sooner we have the main parts of this in, the sooner drivers can test that new
version and hopefully shake the bugs out before the final.
> 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
>
>
> 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)
