You are right of course this was a really big bear, and very cumbersome.
I appreciate all the comments and I'll try to address all the problems. Thanks for the review! Really helpful.
I try and start from the top. I tried several times to break it up. Really. But there never seemed to be a clean break. I see what you did with generated thrift... that really helps... I'll do that.
I am using GIT but some of the techniques were a bit foreign to me a tricky to get all together so I learned as I went along on this patch and I think I have turned the corner but it definitely slowed me down an I backtracked a lot... I think I got it now...
I must say I really did not intend any of the whitespace changes (in general) they just sneak in there when I am not looking I guess. I'll try to keep it tidier.
As to coding conventions, I'll comply... NBD.
And now on the the meat...
I feel pretty strongly that a struct that can optionally do either, is the wrong choice. Let's not make this implementation, or the client-facing interface any more complicated than it needs to be.
I completely agree and implemented the whole thing first using String.
But then I hated the idea of having to go to HEX to get in "blob"/bytes data. This approach let me do both. It also allowed me to serialize Java Objects nicely as bytes. Can you think of a clever way to handle byte streams (AbstractBytes)? But I can live with just String. I agree it is the most flexible.
I really don't see any real performance advantage and the loss of flexibility on the server side is just too much in my opinion.
Does remove_prepared_query support something particular in JDBC (or any other standard)? How will that be used?
It allows you to free the cached
on the server side when a client side PreparedStatement is closed. If not, you will accumulate dead entries until the connection is closed. That could be a lot of dead wood. Seemed the tidy thing to do.
With regard to CqlPreparedResult:
What is the purpose of the count that is returned? How is that used?
What is the purpose of the CqlStatementType returned. How will that be used?
The count is to know how many markers were actually encountered. This number serves as the upper bound for Setxxx parameter indexes. Better than regexing for it... it is exactly what the server side encountered.
The statement type is again a validation of what the server side saw. Remember this happens in 2 steps prepare then execute, and the execute step does not have the CQL text.
But I used it while debugging and I don't seem to use it any more so I guess it could go, but it I thought I might find a use for is so I never did make it go away.
Is CQLStatement.cql only used for logging? If so, should we be keeping a copy of the query string around for that? Maybe we could create a toString that would descend to create the query (or something comparable).
Another "seems useful" so I kept it around. If something goes wrong and you need to go poking around its handy to have attached to the statement (I think).
There are a few places where queries are being logged at DEBUG. That seems too verbose for DEBUG.
I think there was already an instance there at DEBUG and I just added some more. I'll gladly move to TRACE.
Why is Term.bindIndex marked as volatile?
No good reason. I'll fix.
Not a biggie, but how about using "bind" or "bound" instead of "mark" when referring to term position? i.e. needsBind instead of isMarked, or indexBindTerms instead of discoverMarkedTerms
The short answer is because the question marks are often referred to in the spec as "bound variable markers". So I just propagated it. But NBD to change to "bind" theme.
QueryProcessor.prepare seems as though it could be folded into CassandraServer.prepare_cql_query
I guess it could but I liked the way it read better with it split up for all the methods.
It seems as though QueryProcessor.doTheStatement and QueryProcessor.process could be merged into one method.
I factored it out because doTheStatement is used by both process and process_prepared
So in summary, I'll start another pass and would welcome response to my excuses