Logging by interface or current logging status in the project

[uded]

I went through a couple of tickets regarding this issue (at least touch the basis of it), like #407. But I couldn't figure out what is the current status of the logging attitude and approach in the project.

Let me start by stating two very important subjects that should be covered in any further discussion: data security and portability. I would like to focus on the latter, as the first is a bit out of scope and it doesn't seem covered with the current, very simplistic implementation.

Currently, from what I can find, logging goes down to one single approach:

if boil.IsDebug(ctx) {
	writer := boil.DebugWriterFrom(ctx)
	fmt.Fprintln(writer, sql)
	fmt.Fprintln(writer, args...)
}

As this is sufficient for most cases like debugging, etc. it is not always addressing requirements of a more corporate environment, where security auditing teams do require a bit more information regarding certain operations. My problem, personally, boils down to a complexity that arises from using Fprintln(w io.Writer, a ...interface{}), especially the part documented as Spaces are always added between operands and a newline is appended.

At first glance, this is an easy solution and I was expecting to integrate our customers' requirements easily into sqlboiler. But, in a real-life scenario, it is failing rather badly with a complexity level of query parameters used within our apps. In a lamer's term, any space in any of the params and I can no longer easily split the resulting line into actual, usable parameters.

Let's take this example:

INSERT INTO "users" ("email", "password", "full_name") VALUES ($1,$2,$3)

I think the problem should be pretty obvious right away, but let me list the params (modified for privacy):

[email@domain.com $2a$10$sdasfwqfdafsfaadf {First Last true}]

My problem here is, obviously, that the lines already provided by calling Fprintln(w io.Writer, a ...interface{}) are de-structurized. Normalized to a string those are easy to print on the console, but when we have to store this information in a structured log storage system (i.e. Elasticsearch, Graylog, etc.) I am required to provide all params as they are, separately. More like a JSON object rather than a line to write to a file, syslog, or console. Currently, even if I will implement a writer I cannot achieve this in full, there is always a risk of mistakes - and we found a lot of them, unfortunately. Our writer, from 7-liner, grew to like 200 lines of code to accommodate for different scenarios. A pointless exercise, if you would ask me...

As I am writing this long and probably a bit chaotic message I would, in the end, ask the maintainers if there is a plan to change that or are you willing to accept a PR that will keep io.Writer as a general (default) idea of an implementation/direction, but allows an interface implementation that will take SQL and params in one call to enable developers to extend and create their own logging implementation. If so, we are happy to invest some efforts into this as it might be beneficial for us, as well as for anyone else out there.

[aarondl]

I'm indifferent to changes to the logging system so long as it changes across a major version boundary. I don't like it, it's just whats there. The multi-line-per-message thing has irritated me for quite some time. The only requirement I have is that it's trivial to turn it on for developers and there's an easy default implementation for any interfaces that are introduced.

Though as I mentioned in the other thread the purpose of the logging here is 100% for developer troubleshooting only generally during development. It's not filtered or redacted in any way and so I want to be clear that these logs ending up in Elasticsearch is probably a bad thing. Typically the postgresql log_statement type log is much more useful than the sqlboiler logs anyway so you may want to consider using that instead.

[uded]

I do agree with one thing - usually putting logs in some log retaining system is not a good idea, and for many, many reasons I tend to avoid it. But, for another bunch of strange reasons, in an enterprise environment right now, they do a lot of LSM & SIEM for an arm long of reasons, especially when external developers and vendors are involved. As I understand their reasoning, and I accept it in my way, I am obligated to deliver them regardless of my own beliefs. Saying that I need to figure a way to do that with the current choice of libraries, hence my question.

OK, I will sit down with a couple of smart people on our end, and we will try to come up with a design that won't break things but will be easy to use. Plenty of examples out there on Github, so it shouldn't be a big hassle.