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:
Alex Popescu
November 20, 2014, 11:38 PM

see also

Olivier Michallat
February 5, 2015, 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.

Olivier Michallat
March 26, 2015, 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)

Vishy Kasar
March 27, 2015, 3:00 AM

Sure, That works. Thanks.

Fixed

Assignee

Olivier Michallat

Reporter

Vishy Kasar

Labels

PM Priority

None

Affects versions

Fix versions

Pull Request

None

Doc Impact

None

Size

None

External issue ID

None

External issue ID

None

Components

Priority

Major
Configure