This issue will track the implementation of the reference SQL (https://github.com/elastic/apm/issues/12) parsing implementation on all the agents.
_Needs additional information after https://github.com/elastic/apm/issues/12 which blocks this_
@elastic/apm-agent-devs can you please create issues and link them here?
For the agents who already have an SQL parser, should we create issues to update these parsers to look more like the Go parser?
@watson do you mean the parser code? I don't think there's any need to make the code look similar.
Right now we just need to make sure the span names are (at least roughly; preferably exactly) consistent, and we handle the various SQL variants and their differing string literal and comment syntax, etc.
Regarding consistency: if you find there are major discrepancies with other existing implementations, and have concerns over the specified naming, then we can revisit the decisions made in #12. Otherwise, I think we should open issues to make the span names consistent across the agents.
Got'ya - I meant how the parser parses the SQL statement, so I guess the answer is yes: We _do_ need to make issues, even for the agents who already parse SQL.
Do we have a set of test cases we can share to make sure that given SQL statement foo, we get span name bar?
@felixbarny I bumped into this issue by accident - I believe it can be closed, right?
I've created and linked a Python issue. As we have all links now, we can close this out.
Most helpful comment
Yes, there are test cases. See https://github.com/elastic/apm-agent-go/blob/master/internal/sqlscanner/testdata/tests.json and https://github.com/elastic/apm-agent-go/blob/master/module/apmsql/testdata/signature_tests.json.