Provide API to retrieve values of a BoundStatement

Description

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)

Environment

None

Pull Requests

None

Activity

Show:

Vishy Kasar 
March 27, 2015 at 3:00 AM

Sure, That works. Thanks.

Olivier Michallat 
March 26, 2015 at 6:58 PM

, 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)

Olivier Michallat 
February 5, 2015 at 3:49 PM

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.

Alex Popescu 
November 20, 2014 at 11:38 PM

see also

Fixed

Details

Assignee

Reporter

Labels

Affects versions

Fix versions

Components

Priority

Created November 20, 2014 at 10:18 PM
Updated April 14, 2015 at 10:19 PM
Resolved March 27, 2015 at 3:02 PM