feat: allow setting a query comment through a context value

[kylemcc]

This is an enhancement to recently merged comment functionality. This implementation preserves the current functionality, but allows a comment to be set at the time a query is executed.

This can be used like so:

qctx := bun.ContextWithComment(ctx, "traceid:"+traceID)
err := db.NewSelect().
    Model(&things).
    Where("type = ?", t).
    Scan(qctx)

Which, like the Comment() API will produce:

/* traceid:f2e006f2-8494-4ce6-947e-2c77f4c33dc8 */ SELECT * FROM thing WHERE type = 'whatever'

I should note that in this implementation, if a comment is set through a context, it takes precedence over one set on a query using the Comment() API. If the opposite precedence makes more sense, I'm happy to change this.

I know there was some discussion about supporting multiple comments - I'm happy to add some support for that if it's desirable. I think there's good reason to support both mechanisms and have them play nicely together, but maybe that should be discussed separately. For example, the idea of adding a .Comment("descriptive query name") to individual queries, but then being able to combine that with a context that provides a trace ID so that all queries made as part of a given request can be identified. In this case, I would propose that any comment set on the context appear first in the query followed by any set using the Comment() method.

[j2gg0s]

Passing comments through context is a good idea, thank you for your contribution.

1. If both the Context and Comment methods specify a comment, wouldn’t it make more sense to merge them?
2. We can implement the logic in the beforeQuery hook method, right? That way, the intrusion into the code will be minimal.

[kylemcc]

1. If both the Context and Comment methods specify a comment, wouldn’t it make more sense to merge them?

I wouldn't be opposed to merging them - I think there is definitely value there. If I remember correctly, one of the other discussions raised some questions about comment order if multiple comments are specified. So, I think we just need to decide what the proper behavior should be.

2. We can implement the logic in the [beforeQuery](https://github.com/uptrace/bun/blob/master/hook.go#L55) hook method, right? That way, the intrusion into the code will be minimal.

Yes, I think that would be a reasonable way to refactor and DRY up this addition and the existing implementation. Happy to take a pass at that if you'd like.

[j2gg0s]

@kylemcc

I respect your opinion on merging or replacing.
I don’t have much understanding of the use cases for this method.

[kylemcc]

2. We can implement the logic in the [beforeQuery](https://github.com/uptrace/bun/blob/master/hook.go#L55) hook method, right? That way, the intrusion into the code will be minimal.

Yes, I think that would be a reasonable way to refactor and DRY up this addition and the existing implementation. Happy to take a pass at that if you'd like.

I finally had some time to look into this, and it turns out to be a bit more complicated than I realized. the beforeQuery hook doesn't currently have the ability to modify the query. The query is built/formatted before being sent to that hook (see here or here, for example). (I actually tried to implement this as a hook to make it an optional feature, which led me to that discovery). We could make it possible to modify the query in that hook, but in my opinion that would make the code harder to follow.

@kylemcc

I respect your opinion on merging or replacing. I don’t have much understanding of the use cases for this method.

Given the above, I think my suggestion would be to stick with the current implementation where the context comment replaces the comment set on the query/provides an alternate way to set a comment. We can always add support for multiple comments or merging the two if there's demand, but it doesn't seem like anyone is asking for that yet.

[j2gg0s]

I’m sorry for not checking the logic of beforeQuery, which ended up wasting your time.

[kylemcc]

I’m sorry for not checking the logic of beforeQuery, which ended up wasting your time.

No problem :)