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

Already on GitHub? Sign in to your account

Logging interface #52

cmelbye opened this Issue Mar 18, 2014 · 5 comments


None yet
3 participants

cmelbye commented Mar 18, 2014

Do you think it could be useful to use log.Logger and allow the ability to set a custom logger instead of using log.Println? Execv and friends are nice, but it would be great if those logs could be sent somewhere other than STDOUT.


jmoiron commented Mar 18, 2014

You can get the standard logger to point to any io.Writer by calling log.SetOutput. Hopefully this will suffice for your needs.

Obviously, sqlx isn't a logging package. Sadly, the log package is rather simple and not really easily extended by custom loggers.

I'll have to look into what other packages do for logging. I feel like I see the generic standard logger in use pretty often. There are locking issues with trying to use multiple loggers on a single output file, so if I abandon the standard logger, that might lead to some unpredictable results for some people. In the worst case, they might start to lose messages they are currently getting.

cmelbye commented Mar 18, 2014

Oh wow, I didn't know about log.SetOutput, I don't know how I missed that. Thanks!

It seems like using log.Logger and allowing custom loggers would be the right way to do it, but I don't know for sure. For example, see the log/syslog package: http://golang.org/pkg/log/syslog/

@jmoiron jmoiron referenced this issue Jun 14, 2014


Query Logging #66


jmoiron commented Aug 27, 2014

The logging variants are no longer part of sqlx because I felt their convenience was not worth the extra noise in the API documentation. They are trivially implemented in any codebase. Because of that this is not really an issue anymore.

@jmoiron jmoiron closed this Aug 27, 2014

gravis commented Mar 23, 2015

I really like the way logrus is handling this.
Hooks can be registered, and will receive a copy of the log entry. Maybe Exec, Select, etc. could act the same. Adding logging / performance measurement would be easily achived, without creating a new type and wrap all the methods (which I has to do). Wrapping is weak and doesn't support API changes very well :(

gravis commented Mar 23, 2015

(weak -> New methods are not wrapped until we write the code)
(changes -> Need to update all wrappers where API changed)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment