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
[Profiling] Add query backtrace data #954
Conversation
Note: keeping this on hold until doctrine/dbal#3513 is merged. |
<td> | ||
<span class="text-small"> | ||
{% set line_number = trace.line|default(1) %} | ||
{% set file_path = trace.file|format_file(line_number)|striptags|replace({ (' at line ' ~ line_number): '' }) %} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why using |format_file(line_number)
if you remove both the tags (making the file clickable) and the line number ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's for making relative paths
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but why not keeping the full feature of |format_file
which makes them clickable ?
@ottaviano thanks a lot for proposing this feature. I like it a lot! However, as a potential user of this feature, I'd like to see the following trace instead of what you showed in your screenshot: In my opinion, the trace should only display my own code, to show which of my lines of code was responsible for the database query. All the other lines are internal Doctrine stuff which I wouldn't care. But all this is just my opinion, so let's wait and see if others agree. Thanks! |
@javiereguiluz I'm on the fence about this. On one hand, it would definitely make the trace easier to understand, but it may leave holes in the trace regarding "how do we end up here". I believe if we were to do this, we should allow users to toggle this and switch from the shortened trace to the full trace. If we keep the numbering intact, it would show the user that we're omitting some information to make it understandable. Another problem is, what do we remove? For example, what if the query is run because I use a ParamConverter annotation? Hiding |
I think maybe this could be done later if done at all… plus, a lot of similar upstream PRs have been rejected in the past, so IMO we should focus on the PR first before potentially wasting brainpower here. |
So what are the downsides of automatically enabling this when profiling is enabled? I'm not sure about exposing new option just for this. |
Not a fan of having many configuration options either, but in this case I agree that it should be opt-in due to the amount of data that's potentially collected. |
Same is true when |
@ostrolucky I add a new option for disabling this feature by default as the logger saves in memory the trace of each query. When a page runs 10 queries it will contain a lot of data. |
status: need review |
Agree here - we're collecting a lot of data on top of usual profiling data, so it makes sense to add another option for this. As for the rest of the review, I'll hold off until there's something to review: with being closed, the functionality needs to be moved here. I would suggesting putting it in the |
79695a3
to
e304f01
Compare
I moved status: need review |
I've updated the PR a little bit:
Thanks @ottaviano for adding this great feature! |
very nice, thank you @alcaeus 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Twig part could be nicer, but ok for now
So glad to see this so long awaited feature finally be delivered! Great job @ottaviano! |
dbal pull request for sql logger