Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Query-Logging with prepared statements #1068

Open
wakille opened this issue Aug 17, 2023 · 8 comments
Open

Query-Logging with prepared statements #1068

wakille opened this issue Aug 17, 2023 · 8 comments
Labels
Category/Enhancement Overall improvements, not necessarily bug fixes

Comments

@wakille
Copy link

wakille commented Aug 17, 2023

Hello,
for my use case it is important to log the exact query executed, which is by default not possible with prepared statements, as I unterstand. (You can only see the prepared statement before the preparation). Is there any good practice on achiving this with prepared statements or do you plan to include this feature in upcoming releases ?

Thanks

@zann1x
Copy link
Contributor

zann1x commented Aug 17, 2023

There is no supported way to do this. logger::start_query is getting called way too early to even have a chance knowing about any parameters. This is done so logging is effective whether the query succeeds or not.

I can't speak of any plans of including such a feature, though.

@wakille
Copy link
Author

wakille commented Aug 18, 2023

For me you exactly explained the main issue with the current logging, I cant see afterwards if the query succeded or not. And I cant track afterwards what has been written to the database. How big do guess the effort to enable soci to support the logging described previously by me ?

@zann1x
Copy link
Contributor

zann1x commented Aug 18, 2023

Generally speaking, you can assume that a query has succeeded when no exception is thrown.
In terms of effort for adding this feature, I'd say it's probably just a matter of adding something like logger::execute_query(std::string query_with_values) in the execution step of soci::statement. I can definitely see the benefit in terms of tracing queries here.
Feel free to create a PR for that!

@wakille
Copy link
Author

wakille commented Aug 18, 2023

Is there any plan for a 4.x version release ?

@zann1x
Copy link
Contributor

zann1x commented Aug 18, 2023

I think that the next release is mostly blocked by #954, but I can't tell you when we're able to land these changes.

@vadz vadz added the Category/Enhancement Overall improvements, not necessarily bug fixes label Aug 21, 2023
@vadz
Copy link
Member

vadz commented Aug 21, 2023

FWIW I agree that having a way to log the values of the parameters (if I understand correctly what you'd like to do here?) would be useful. And I'll try to merge #954 and make a release a.s.a.p.

@wakille
Copy link
Author

wakille commented Aug 21, 2023

Yeah, that would be really nice. I looked into the sqlite3 documentation and there is a method to get the expanded query as string. The main issue I saw in implementing this in your project is, that you are not logging in the backends. So either the way how you execute the the prepared query’s or the way you log has to change for this. I can also help implement this if you can give man like some plan how you want it implemented. Could we take this logging into the upcoming release ?

@vadz
Copy link
Member

vadz commented Aug 21, 2023

As statement_impl already has a session_ member, it could pass session_.get_logger() to some new backend log_statement_execution() function. Am I missing some difficulty here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Category/Enhancement Overall improvements, not necessarily bug fixes
Projects
None yet
Development

No branches or pull requests

3 participants