When queries are slow, we log the query statement that was slow. When the statement is a bound prepared statement, the only thing we can do now is dump the prepared statement. When client makes millions of requests with same prepared statement, this is not so useful. We need to be able to dump the actual values to be useful.
Looking at the BoundStatement, it is serializing the values in the bind method() and not retaining the original values. It may be beneficial to keep the original values for the life of BoundStatement so we can return them in getValues()
If we all agree this is useful, I can create a patch and attach it here.
Final API: no getValues, but individual getters for each field (see discussion in comments)
We already do that on the 2.1 branch. The problem in retaining the original values is that we might not have them in the first place (if setBytesUnsafe was used).
What we do in 2.1 is provide the same getters as Row, that deserialize the values from the internal buffers. That's a small performance hit, but I think it's acceptable for this kind of use case.
Also, we should avoid duplicating the code of the getters. That's a bit tricky as we can't use inheritance (BoundStatement already has a parent). That's also handled in 2.1.
There's some stuff in that I want to merge to 2.1 before, but then I'll backport the code.
, I'm a bit reluctant to expose a getValues() method, because I think in most cases the types will be needed as well.
For example, you mention logging as your primary use case. In 2.0.10 we'll expose a new DataType.format method to pretty-print the values, so you'll want to use that instead of doing the formatting yourself. So in that case getValues() is not that useful, because you'll need to inspect the statement's metadata anyway to get the types. Better do it in a single loop:
Would the above work for you? (assuming that format and getObject exist)
Sure, That works. Thanks.