You'd probably have to expose a version of executeOnceInternal that directly expose the QueryOptions, but I don't think it would shock anyone.
That said, I'm not entirely convinced that modifying the protocol is the way to go for CASSANDRA-7304, so you might want to start first by explaining what you plan on doing on the ticket so we get some kind of consensus on if and how we want to get this. -- Sylvain On Tue, Jun 17, 2014 at 12:30 PM, Peer, Oded <oded.p...@rsa.com> wrote: > I am trying to solve CASSANDRA-7304 by adding a new flag to QueryOptions. > I changed the core code and now I want to add a unit test. > > I followed the logic in TupleTypeTest and CQLTester however in order to > use this framework I'd need to change the > QueryProcessor.executeOnceInternal() to accept the new flag. I am sure > there must be another way to do this, without changing core code only for > testing purposes. > I thought of invoking ExecuteMessage but that requires invoking also a > PreparedMessage and it's a bit complicated for the test I want to perform. > I can change the driver code to include the new flag but this seems like a > big overhead and I can't use it in unit tests. > > What would be the best way for unit testing a new flag in QueryOptions, > that has to do with PreparedStatements? > > Oded >
