feat: uniform rendering of stack trace from failed DB operations#9364
feat: uniform rendering of stack trace from failed DB operations#9364paulbalandan wants to merge 2 commits intocodeigniter4:4.6from
Conversation
6f1ca05 to
79a9c97
Compare
|
The last time I checked, the full stack track was available: #9338 (comment) and it looks the same for all the drivers. Are there any differences (I may have missed something)? Can you give me an example? |
|
I am assuming they did not see the full stack trace since Before this PR:
Postgres (stringified error exception) OCI8 (stringified error exception): |
|
After this PR:
|
bf0159a to
196c605
Compare
196c605 to
40dd62a
Compare
|
The non-determinism of the tests is really frustrating 🤷🏻♂️ |
|
Yes. the database package is very thick. I'm afraid to fix him. |
|
@paulbalandan Ok, I get it now. Thanks! |
|
👋 Hi, @paulbalandan! |
|
As I don't have the mental energy to resolve the DB errors, this can wait. |
Description
Closes #9338
All DB drivers except SQL Server logs (with 'error' level) a full stack trace of any failed DB executions via the thrown exception. For SQL Server, the log only includes the message produced by
sqlsrv_errors(). Moreover, there's inconsistency with regard to Postgre and OCI8 drivers. Sincepg_query()andoci8_execute()only throws because of our error handler, the stack trace also includes the error handler (the[internal function]stack).This PR aims to make consistent the log output of these drivers by using the same trace rendering. This is already achieved by the private
Exceptions::renderBacktrace()method for the thrown exceptions, so this PR extracts it to a new functionrender_backtraceand uses that to format the trace. Also, trace coming from the error handler are removed.Checklist: