-
Notifications
You must be signed in to change notification settings - Fork 327
postgres: DBM full service fallback w/ prepared statements #3186
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
Conversation
Overall package sizeSelf size: 4.18 MB Dependency sizes
🤖 This report was automatically generated by heaviest-objects-in-the-universe |
3dd5e98
to
0864b0f
Compare
Codecov Report
@@ Coverage Diff @@
## master #3186 +/- ##
==========================================
- Coverage 86.57% 86.54% -0.03%
==========================================
Files 333 331 -2
Lines 11934 11894 -40
Branches 33 33
==========================================
- Hits 10332 10294 -38
+ Misses 1602 1600 -2
... and 2 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
0864b0f
to
5f2d2b1
Compare
const query = { | ||
name: 'pgSelectQuery', |
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.
This was actually an example of the bug happening. The previous test had a name and was therefore a prepared statement. The test asserts that the traceparent is present in the comment but it should actually not be present.
- when DBM is set to full service - the DBM comment falls back to service mode - but only when sending a prepared statement - without this, each prepared statement query is technically different - this causes the pg library to fail as it does an exact string check of the query - ideally the pg library would somehow parse out and not consider comments - at any rate this brings parity with other tracer implementations - see brianc/node-postgres#2735 - previously attempted in 0ff9465
- when DBM is set to full service - the DBM comment falls back to service mode - but only when sending a prepared statement - without this, each prepared statement query is technically different - this causes the pg library to fail as it does an exact string check of the query - ideally the pg library would somehow parse out and not consider comments - at any rate this brings parity with other tracer implementations - see brianc/node-postgres#2735 - previously attempted in 0ff9465
- when DBM is set to full service - the DBM comment falls back to service mode - but only when sending a prepared statement - without this, each prepared statement query is technically different - this causes the pg library to fail as it does an exact string check of the query - ideally the pg library would somehow parse out and not consider comments - at any rate this brings parity with other tracer implementations - see brianc/node-postgres#2735 - previously attempted in 0ff9465
- when DBM is set to full service - the DBM comment falls back to service mode - but only when sending a prepared statement - without this, each prepared statement query is technically different - this causes the pg library to fail as it does an exact string check of the query - ideally the pg library would somehow parse out and not consider comments - at any rate this brings parity with other tracer implementations - see brianc/node-postgres#2735 - previously attempted in 0ff9465
- when DBM is set to full service - the DBM comment falls back to service mode - but only when sending a prepared statement - without this, each prepared statement query is technically different - this causes the pg library to fail as it does an exact string check of the query - ideally the pg library would somehow parse out and not consider comments - at any rate this brings parity with other tracer implementations - see brianc/node-postgres#2735 - previously attempted in 0ff9465
- when DBM is set to full service - the DBM comment falls back to service mode - but only when sending a prepared statement - without this, each prepared statement query is technically different - this causes the pg library to fail as it does an exact string check of the query - ideally the pg library would somehow parse out and not consider comments - at any rate this brings parity with other tracer implementations - see brianc/node-postgres#2735 - previously attempted in 0ff9465
What does this PR do?
Motivation
Plugin Checklist